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Preface 


The  research  discussed  in  this  report  investigates  decentralized  real-time  scheduling  in 
the  context  of  the  Alpha  Operating  System.  Four  goals  have  been  identified  for  this  work: 
(1)  to  identify  areas  where  Alpha  would  benefit  from  additional  decentralized  real-time 
scheduling  research;  (2)  to  define  decentralized  real-time  scheduling  algorithms  for  incorpo¬ 
ration  into  Alpha;  (3)  to  develop  criteria  to  determine  the  efficacy  of  these  algorithms;  and 
(4)  to  evaluate  the  algorithms. 

A  two-pronged  approach  has  been  adopted  to  satisfy  these  goals.  On  one  front.  Alpha 
Release  1  is  studied  and  evaluated.  This  effort  identifies  and  evaluates  the  relevant  real¬ 
time  scheduling  facilities  in  Alpha,  revealing  open  questions  that  require  further  research. 
On  the  second  front,  research  is  performed  that  will  improve  Alpha  in  future  releases.  In 
some  cases,  this  work  focuses  on  questions  identified  by  the  analysis  of  Alpha  Release  1, 
while  in  other  cases  it  extends  Alpha’s  capabilities  in  directions  previously  identified — for 
example,  providing  the  foundation  for  the  real-time  transaction  facility.  In  the  future,  the  re¬ 
sults  of  this  research  will  be  put  into  practice  in  Alpha. 

This  report  is  divided  into  three  sections,  one  evaluating  Alpha  Release  1  and  the  others 
reporting  on  new  scheduling  research. 

Part  A  describes  a  demonstration  program  that  was  used  to  study  various  scheduling  pol¬ 
icies,  including  a  Best-Effort  Scheduler,  in  the  context  of  Alpha  Release  1.  The  program  was 
designed  specifically  to  isolate  scheduling  policy  decisions,  to  provide  a  graphic  display  of 
scheduling  algorithm  behavior,  and  to  measure  scheduler  performance.  Each  scheduling  poli¬ 
cy  was  analyzed  under  a  variety  of  workloads,  with  Alpha's  Best-Effort  Scheduler  perform¬ 
ing  well.  The  results  of  this  investigation  are  included  in  Part  A. 

Part  B  addresses  the  issue  of  scheduling  distributed  computations.  It  outlines  ongoing 
work  to  model  decentralized  and  distributed  computations,  to  describe  best-effort  scheduling 
algorithms  appropriate  for  this  model,  and  to  study  the  amount  and  type  of  information  that  is 
required  to  schedule  the  computations  effectively. 

Part  C  extends  best-effort  techniques  to  schedule  dependent  activities  in  a  supervisory 
control  real-time  system.  Dependent  activities,  which  share  common  resources  such  as  data 
and  devices,  may  also  exchange  signals  to  coordinate  their  actions.  This  study  provides  an 
analytic  framework  to  formally  investigate  various  scheduling  policies.  Several  useful  proper¬ 
ties  of  the  resulting  scheduling  algorithm  are  proven  within  this  framework.  In  addition,  sim¬ 
ulation  results  are  presented  that  demonstrate  the  effectiveness  o i  the  algorithm  when  com¬ 
pared  to  other  algorithms.  (Part  C  is  actually  a  draft  of  a  doctoral  dissertation.  As  such,  it  is 
expected  that  it  will  be  revised  and  augmented  in  order  to  produce  the  final  version  of  the  dis¬ 
sertation.) 

Note:  This  Final  Technical  Report  and  the  Six-Month  Technical  Report  (Interim  Techni- 
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cal  Report)  together  detail  the  research  performed  for  this  contract.  While  the  material  pre¬ 
sented  in  Part  C  of  this  report  updates  and  expands  on  Part  A  of  the  Interim  Technical  Re¬ 
port;  Part  B  of  the  Interim  Technical  Report,  which  described  the  completed  analysis  of  the 
Communication  Subsystem  of  Alpha  Release  1,  is  not  repeated  or  revised  in  this  document. 
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Abstract 

This  document  describes  our  expenence  with  a  set  of  experiments  designed  to  evaluate 
the  behavior  and  performance  of  various  scheduling  policies  for  the  Alpha  real-time  distribut¬ 
ed  operating  system  [Northcutt  87],  Alpha  is  an  adaptable  decentralized  operating  system 
being  developed  as  a  part  of  the  Archons  project’s  on-going  research  into  real-time  distribut¬ 
ed  systems.  Timely  completion  of  an  application’s  computational  activities  is  one  of  the 
most  important  functions  of  a  real-time  system.  Therefore,  the  proper  scheuu1  rig  of  those  ac¬ 
tivities  is  of  critical  importance. 

The  Alpha  programming  model  provides  simple  mechanisms  for  an  application  to  specify 
its  timeliness  requirements.  The  scheduler  may  consider  this  time  constraint  information 
when  scheduling  activities  for  execution.  To  gauge  the  effectiveness  of  Alpha  as  an  operat¬ 
ing  system  for  real-time  applications,  an  understanding  of  its  scheduling  facility  is  neces¬ 
sary.  To  this  end,  a  study  of  the  effects  of  various  different  scheduling  policies  was  made. 
To  evaluate  these  policies,  a  real-time  application  was  created  to  serve  as  an  experimental 
workload.  The  application  was  designed  to  simplify  the  modeling  of  tasks  with  a  wide  range 
of  timeliness  requirements  and  to  provide  a  visual  indication  of  scheduler  performance. 

Alpha  provides  a  clean,  well-defined  interface  between  the  scheduling  subsystem  and 
the  kernel  proper.  A  general  scheduler  framework,  independent  of  any  specific  policy,  has 
been  implemented  to  simplify  the  development  and  substitution  of  different  policy  modules. 
This  framework  gready  simplifies  the  experimental  comparison  of  different  policies.  To  date, 
eight  different  scheduling  policies  have  been  implemented  for  Alpha.  Five  of  these  policies 
are  examined  in  this  document — preemptive  round-robin,  static  priority,  dynamic  deadline, 
shortest  processing  time,  and  Best-Effort  [Locke  86]. 

The  experiments  were  designed  to  compare  the  application-level  behavior  of  various 
scheduling  policies  under  a  variety  of  loading  conditions.  Each  policy  was  judged  based  on 
criteria  such  as  how  well  the  application  timeliness  requirements  were  met  and  what  fraction 
of  the  potential  value  of  the  application  was  obtained.  The  experimental  results  were  then 
studied  to  develop  empirical  observations  about  the  relative  behavior  of  each  scheduling  poli¬ 
cy  and  to  derive  an  understanding  of  the  scheduling  decisions  that  were  made. 
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1.  Introduction 

This  document  describes  the  experience  of  the  Archons  research  project  in  evaluating  a 
set  of  scheduling  policies  for  use  in  the  Alpha  distributed  real-time  operating  system.  Alpha 
is  unique  among  operating  systems  in  the  problem  area  it  seeks  to  address:  distributed,  su¬ 
pervisory-level,  real-time  command  and  control.  This  problem  area  dictates  some  special  re¬ 
quirements  that  the  system  must  fulfill.  These  requirements  are  associated  chiefly  with  the 
need  to  manage  resources  in  a  timely  and  decentralized  fashion.  The  .Alpha  programming 
model  permits  the  convenient  expression  of  the  timeliness  requirements  of  an  application. 
The  manner  in  which  the  active  scheduling  policy  uses  this  information  determines  how  well 
the  timeliness  requirements  are  satisfied.  This  set  of  experiments  examines  the  behavior 
and  performance  of  five  different  scheduling  policies  that  have  been  implemented  for  Alpha. 
Before  examining  these  policies  or  the  experiments  in  detail,  however,  it  is  useful  to  under¬ 
stand  the  nature  and  requirements  of  Alpha. 

1.1  The  Alpha  Operating  System 

The  Alpha  operating  system  is  unique  because  of  the  requirements  imposed  by  its  appli¬ 
cation  domain.  As  a  distributed  real-time  command  and  control  system,  Alpha  is  intended  to 
support  applications  where  most  of  the  activities  in  the  system  have  stringent  time  con¬ 
straints  that  are  a  matter  of  correctness  rather  than  convenience — the  safety  of  human  life 
and  property  may  be  dependent  on  the  correct  functioning  of  the  system.  In  addition,  the  dis¬ 
tributed  nature  of  the  system  also  places  unusual  demands  on  Alpha.  Even  though  the  sys¬ 
tem  consists  of  a  collection  of  physically  dispersed  processing  elements,  system  computation 
resources  must  be  managed  so  as  to  cooperatively  perform  a  single  mission,  rather  than 
treated  (as  is  currently  common)  as  a  network  of  communicating,  but  otherwise  independent 
and  unrelated  individual  processing  elements. 

The  Alpha  programming  model  directly  supports  these  needs  [Northcutt  88b].  From  the 
viewpoint  of  the  programmer,  the  physically  dispersed  system  may  be  logically  viewed  as  a 
centralized  one.  The  basic  abstractions  in  Alpha  include  objects ,  threads ,  and  operation  invo¬ 
cations.  In  Alpha,  an  object  is  defined  as  a  logically  related  collection  of  data  and  the  code 
used  to  manipulate  that  data.  The  external  interface  to  an  object  consists  of  the  set  of  opera¬ 
tions  that  may  be  performed  on  the  object,  and  represents  the  only  means  of  accessing  the 
object’s  encapsulated  data.  The  basic  unit  of  activity  in  the  Alpha  system  is  known  as  a 
three  i,  which  is  a  representation  of  a  logical  point  of  program  execution.  Threads  are  the  en¬ 
tities  which  animate  the  otherwise  passive  objects  in  the  system.  Threads  move  between 
objects  by  means  of  operation  invocations.  Operation  invocations  are  similar  in  some  wavs 
to  procedure  calls,  accepting  and  returning  parameters  in  much  the  same  way. 

In  Alpha,  there  may  be  any  number  of  threads  executing  within  a  single  object.  Further¬ 
more,  because  objects  may  be  on  any  physical  processing  element,  threads  may,  as  a  result, 
move  between  the  processing  nodes  in  the  system.  When  a  thread  is  created,  it  begins  its 
execution  with  the  invocation  of  some  operation  on  an  object.  The  thread  continues  execu- 
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tion  until  this  initial  operation  is  complete,  at  which  point  it  is  deleted.  In  the  process  of  exe¬ 
cuting  any  operation,  a  thread  may  invoke  operations  on  other  objects,  thereby  transferring 
the  thread  into  a  new  object  (which  may  be  on  a  different  node).  If  the  target  of  an  invocation 
is  on  a  different  node,  the  thread  state  (including  the  current  time  constraints)  is  transferred 
to  the  destination  node. 

It  is  important  to  recognize  the  difference  between  this  programming  model  and  that  of 
systems  which  support  the  process-message  model.  In  the  process  model,  a  unit  of  computa¬ 
tional  activity  is  tightly  bound  to  a  piece  of  code  and  a  physical  processing  element.  When  an 
application  is  organized  into  objects  which  may  be  used  by  many  system  activities,  it  does 
not  make  sense  to  confute  points  of  control  to  specific  code  segments  which  belong  exclusive¬ 
ly  to  each  thread.  The  thread  abstraction  in  Alpha  represents  the  essence  of  an  abstract 
computational  activity,  and  is  not  burdened  by  unnecessary  artifacts.  A  thread  represents  a 
locus  of  program  control  and  the  current  attributes  the  activity  (e.g.,  its  time  constraints). 
Threads  move  between  objects  without  regard  to  their  physical  location,  and  do  not  incur 
scheduling  overhead  as  a  result  of  each  inter-object  transition. 

With  respect  to  the  real-time  objectives  of  the  system,  the  single  most  important  re¬ 
source  that  the  Alpha  system  manages  is  the  processing  cycles  available  to  the  application. 
Accordingly,  processor  scheduling  has  been  a  topic  of  great  interest  to  the  Archons  project 
for  many  years.  The  concept  of  rime-value  functions  has  been  developed  to  describe  the  time 
constraints  of  activities  in  real-time  systems.  Time-value  functions  were  originally  devel¬ 
oped  by  E.  Douglas  Jensen  in  the  context  of  ballistic  missile  defense  [Jensen  75].  The  con¬ 
cept  was  subsequently  developed  by  the  Archons  Project  students  and  staff  at  CMU,  and 
was  incorporated  in  the  Alpha  operating  system  [Northcutt  88a], 

As  a  result  of  the  previous  work  in  this  area,  it  has  become  clear  that  the  algorithms 
needed  to  perform  time-driven  resource  management  are  computationally  demanding.  In  ad¬ 
dition,  a  distributed  real-time  system  must  also  be  capable  of  dealing  with  the  exceptions 
and  unexpected  events  that  may  occur  as  a  result  of  the  application  environment.  Because  of 
its  great  importance  and  demanding  requirements,  the  Alpha  scheduling  subsystem  has  be¬ 
come  the  center  of  great  attention  and  much  effort  has  been  directed  towards  it  in  the  course 
of  developing  practical  solutions  to  the  problem  of  time-driven  resource  management.  In  Al¬ 
pha,  the  scheduling  subsystem  has  been  carefully  partitioned  from  the  rest  of  the  system  and 
a  separate  processing  element  is  provided  for  it.  Furthermore,  the  scheduling  subsystem 
was  designed  to  allow  the  simple  and  straightforward  substitution  of  different  scheduling  al¬ 
gorithms,  for  the  purpose  of  evaluation  and  comparison. 

1.1.1  Real-Time  Scheduling  Requirements 

In  real-time  systems,  the  timeliness  of  a  computation  is  as  much  a  part  of  correctness  as 
is  calculating  the  correct  value.  Threats  to  human  life  and  property  are  the  expected  results 
of  failure  to  meet  either  criteria.  Most  current  approaches  to  meeting  application  time  con¬ 
straints  involve  the  use  of  a  sufficiently  large  amount  of  excess  resources  to  ensure  that  the 
timeliness  needs  are  met.  This  viewpoint  is  evident  in  the  common  belief  that  a  real-time 
operating  system  is  one  that  has  fast  context  switching  times  and  rapid  interrupt  handling. 
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Under  this  definition,  any  operating  system  running  on  a  fast  enough  processor  would  be  real¬ 
time.  What  is  really  needed,  however,  are  scheduling  techniques  that  make  the  best  possi¬ 
ble  use  of  processor  cycles,  both  when  there  are  enough  resources  to  fully  satisfy  the  activi¬ 
ties  in  the  system,  and  when  there  are  not  enough  cycles  to  meet  all  of  an  application  time 
constraints. 

Some  current  approaches  to  resource  management,  spawned  from  the  excess  resources 
school,  involve  the  use  of  “guarantees”  about  resouice  availability.  This  brand  of  manage¬ 
ment  can  be  the  source  of  a  great  many  problems,  and  is  in  itself  antithetical  to  providing  the 
best  use  of  the  resources  in  a  system.  It  is  impossible  to  make  any  guarantees  about  re¬ 
source  availability  unless  the  system  designer  is  willing  to  permit  extremely  urgent  excep¬ 
tion  conditions  to  be  ignored  in  favor  of  the  less  important  ones  which  have  been  guaran^d 
the  resources  needed.  Adding  more  resources  to  the  system  merely  postpones  the  inevita¬ 
ble  moment  when  even  they  will  not  be  sufficient. 

Responsiveness  to  time  constraints  should  be  based  not  on  guarantees  but  on  system 
software  that  does  the  best  possible  job  (according  to  some  meaningful  application-level  def¬ 
inition)  at  any  given  moment.  This  includes  not  only  times  when  there  are  sufficient  resourc¬ 
es,  but  also  times  when  unexpected  events  occur  and  there  are  not  enough  resources  to  han¬ 
dle  every  need  of  the  application.  Because  many  real-time  systems  are  based  on  the  belief 
that  is  possible  to  make  guarantees  about  resource  availability,  they  do  not  even  address  be¬ 
havior  in  overload.  As  a  result,  when  overloads  inevitably  occur,  they  are  handled  poorly. 
Oi.e  form  of  good  performance  in  overload  is  if  ti.e  system’s  performance  degrades  propor¬ 
tionally  to  the  amount  of  overload.  Most  existing  systems  experience  complete  failure  when 
overloads  occur.  If  the  system  is  designed  to  have  so  much  computation  power  that  this  will 
almost  never  happen,  it  could  represent  a  serious  waste  of  resources  in  the  normal  case.  If, 
on  the  other  hand,  the  system  is  designed  for  lower  performance  and  does  not  have  sufficient 
computational  resources,  system  failure  will  occur.  The  optimum  solution  seems  to  be  that 
the  system  should  have  sufficient  computational  resources  to  perform  the  absolutely  vital 
system  functions  in  the  worst  case.  This  way,  the  system  does  not  fail  in  overload,  but  in¬ 
stead  postpones  or  does  not  perform  the  activities  of  lesser  importance  in  favor  of  those  that 
are  vital  to  successful  mission  completion. 

1.1.2  Distribution  Requirements 

To  be  most  effective,  a  mission-oriented  distributed  system  must  be  strongly  connected, 
and  must  perform  its  activities  as  a  whole  in  a  cooperative  (as  opposed  to  competitive)  fash¬ 
ion.  Alpha  is  the  first  distributed  operating  system  to  be  truly  decentralized.  There  is  no 
central  entity  whose  failure  would  doom  the  system.  The  Alpha  system  provides  support  for 
cooperation  on  a  peer  level  which  is  implemented  so  that  it  can  be  logically  viewed  by  the 
programmer  as  having  all  the  behavioral  characteristics  (in  terms  of  synchronization  and  co¬ 
herency)  that  a  centralized  system  provides 

The  decentralized  nature  of  Alpha  has  several  important  consequences  with  respec’  to 
scheduling  the  application  processors.  The  primary  example  involves  time -constrained  com¬ 
putations  that  span  multiple  nodes.  Proper  handling  of  these  distributed  computations  re- 
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quires  that  the  scheduling  subsystem  must  be  made  aware  of  the  time  constraints  associat¬ 
ed  with  a  thread  when  it  arrives  at  a  node.  If.  when  a  thread  spans  a  series  of  nodes,  a  fail¬ 
ure  occurs  in  one  of  the  nodes  in  the  chain,  the  computation  performed  by  that  node  is  lost 
and  the  computations  based  on  its  results  are  invalidated.  Therefore,  the  head  of  the  thread 
must  move  back  to  the  point  prior  to  the  first  failure  and  Alpha  must  intelligently  schedule 
cleanup  activities  for  the  orphaned  threads.  This  includes  removing  time  constraints  that 
were  acquired  on  or  after  the  broken  node. 

1.2  Testing  Alpha  Scheduling  Policies 

The  importance  of  the  scheduling  function  in  the  .Alpha  system  demands  that  the  policies 
used  to  allocate  processing  resources  meet  (as  well  as  possible)  the  requirements  of  the  ap¬ 
plication.  It  is  of  course  unpossible  to  know  in  advance  what  characteristics  any  given  appli¬ 
cation  may  requu-e  of  a  scheduling  policy.  Certain  characteristics  have,  in  the  project’s  expe¬ 
rience.  proven  to  be  especially  helpful  in  real-time  command  and  control  applications.  Using 
these  characteristics  as  a  starting  point,  requirements  for  an  application  to  run  on  the  Alpha 
system  to  exercise  each  scheduling  policy  on  each  of  these  points  were  devised. 

1.2.1  Test  Objectives 

The  scheduling  policies  examined  in  this  report  vary  widely  in  such  characteristics  as  the 
amount  and  kind  of  information  required,  the  computation  tune  used  in  determining  a  sched¬ 
ule,  and  the  criteria  used  to  rank  competing  threads  into  a  schedule.  A  number  of  aspects  of 
each  scheduling  policy's  behavior  are  of  interest  in  this  effort.  The  primary  intent  of  this 
work  was  to  evaluate  the  relative  abilities  of  various  scheduling  policies  when  given  a  cer¬ 
tain  amount  of  information  by  the  application.  Also  of  interest  is  the  examination  and  charac¬ 
terization  of  the  behavior  of  each  scheduling  policy  within  the  context  of  Alpha. 

The  policies  tested  here  were  evaluated  under  both  underload  and  overload  conditions. 
Because  the  policies  each  use  a  subset  of  the  available  tune  constraint  information  and  be¬ 
cause  each  policy  makes  a  different  use  of  this  information,  the  behavior  of  an  application  can 
varv  greatly  from  policy  to  policy  and  between  underload  and  overload.  It  was  of  particular 
interest  to  discover  how  well  the  overload  performance  of  the  scheduling  policies  provided  for 
graceful  degradation  of  system  function.  In  general,  if  a  system  is  not  overloaded,  a  schedul¬ 
er  should  be  able  to  create  a  schedule  that  permits  all  the  activities  in  the  system  to  com¬ 
plete  before  their  critical  times  (the  time  at  which  completion  of  the  activity  would  no  longer 
result  in  any  value  to  the  system,).  On  the  other  hand,  there  are  scheduling  policies  that  do 
not  make  use  of  all  of  the  application-specified  information  that  is  available  to  the  scheduling 
subsystem  in  Alpha,  and  cannot  attain  even  this  level  of  performance.  Other  policies  make 
use  of  the  full  information  available  in  the  time-value  functions,  but  use  different  criteria  to 
determine  schedules.  The  characterization  of  the  resultant  application-level  behavior  was  of 
great  interest  in  these  experiments. 

Also  examined  was  the  response  of  various  scheduling  policies  to  particular  scenarios 
representing  specific  resource  management  problems.  Furthermore,  the  sensitivity  of  sched¬ 
uling  policies  to  variations  in  their  input  parameters  was  also  of  interest,  and  experiments 
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were  carried  out  to  determine  the  extent  10  which  the  values  of  various  parameters  affect  the 
schedules  generated  by  each  policy.  These  experiments  provide  clues  about  how  the  sched¬ 
uling  policies  respond  to  small  variations  in  constraints  and  how  each  policy  makes  trade¬ 
offs  when  faced  with  difficult  resource  management  decisions. 

It  was  also  intended  that  the  results  of  this  effort  would  include  additional  information 
about  the  effectiveness  of  Alpha's  design  and  performance.  One  item  of  particular  interest  is 
the  effectiveness  of  the  separation  of  policy  from  mechanism  within  the  scheduling  sub¬ 
system.  Alpha  was  designed  with  a  scheduling  framework  into  which  a  wide  range  of  user- 
specified  scheduling  policies  can  be  inserted.  This  process  of  providing  a  collection  of  mecha¬ 
nisms  and  not  mandating  a  specific  policy  is  a  characteristic  of  Alpha  operating  system  as  a 
whole. 

An  important  objective  of  this  work  is  the  evaluation  of  scheduling  policies  to  find  ones 
which  exhibit  the  desired  behavior  with  respect  to  handling  time  constraints  imposed  by  ape¬ 
riodic  events.  It  was  hoped  that  the  empirical  examination  of  the  behavior  of  different  sched¬ 
uling  policies  would  suggest  what  which  class  of  policies  performs  the  best  under  conditions 
representative  of  real-time  command  and  control  applications. 

1.2.2  Test  Application  Requirements 

In  order  to  meet  these  objectives,  it  was  necessary  to  come  up  with  a  sample  application 
which  both  contained  the  elements  of  a  supervisory  real-time  control  application  and  could  il¬ 
lustrate  in  clear  terms  the  efficacy  of  each  scheduling  policy  with  regards  to  its  ability  to  suc¬ 
cessfully  meet  the  given  time  constraints.  The  application  must  be  one  where  it  is  possible 
to  separate  the  effects  of  the  scheduling  policy  from  the  other  functions  which  affect  the  be¬ 
havior  of  the  application.  To  meet  these  two  objectives,  the  application  must  contain  certain 
elements.  First  of  all,  the  sample  application  must  contain  hard  time  constraints — i.e.  there 
must  exist  activities  which  demand  response  within  a  specific  amount  of  time.  If  the  applica¬ 
tion  responds  to  a  time-critical  event  after  that  time,  the  response  will  be  of  no  benefit  to  the 
system.  In  most  real-time  systems,  there  are  such  activities  which  simply  must  be  complet¬ 
ed  before  a  certain  time  has  elapsed.  However,  there  also  exist  applications  where  the  pen¬ 
alty  for  not  meeting  a  time  constraint  may  not  be  the  loss  of  the  system,  and  in  fact  may  not 
be  very  severe  at  all.  Such  activities  are  known  as  soft  time  constraints. 

Another  important  feature  required  of  the  test  application  was  the  presence  of  multiple 
schedulable  entities.  It  is  necessary  for  the  scheduler  to  have  a  reasonably  large  number  of 
tasks  contending  for  processor  cycles.  Having  multiple  concurrent  activities  helps  ensure 
that  the  scheduler  must  constandy  make  scheduling  decisions,  and  that  die  effects  of  those 
decisions  will  be  visible  at  the  application  level.  A  small  number  of  activities  might  reduce 
the  demands  on  the  system  to  a  point  where  there  was  no  longer  any  need  for  the  scheduler 
to  be  intelligent  about  allocating  processor  cycles.  Having  multiple  activities  that  each  per¬ 
form  a  similar  function  but  with  different  time  constraints  would  make  it  easier  to  see  the  im¬ 
pact  of  the  time  constraints  clearly. 
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2.  Scheduler  Evaluation  System 

After  considerable  thought,  an  application  was  devised  which  meets  most  of  the  criteria 
expressed  in  the  previous  chapter.  The  abstract  problem  chosen  for  these  experiments  is  the 
task  of  keeping  several  bouncing  balls  in  the  air  by  means  of  moving  motorized  paddles. 
Each  ball  has  a  paddle  assigned  to  catch  it.  The  application  program  that  executes  on  Alpha 
is  responsible  for  controlling  the  motion  of  the  paddles  to  ensure  that  balls  are  not  dropped. 
The  application  program  receives  sensor  data  giving  the  position  and  velocity  of  the  balls, 
and  produces  a  series  of  actuator  commands  to  move  the  paddles  into  position. 

The  experimental  environment  is  composed  of  two  major  components — the  mechanical 
subsystem  that  includes  the  physical  environment  in  which  the  control  activity  exists  (i.e., 
the  balls,  paddles,  walls,  ceiling,  floor,  gravity,  etc.),  and  the  control  subsystem  that  includes 
the  application  program  that  performs  the  control  functions,  the  Alpha  operating  system,  and 
the  Alpha  testbed  on  w'hich  it  all  runs.  Figure  1  illustrates  the  major  components  of  the  ex¬ 
perimental  environment. 

In  the  work  descnbed  here,  the  mechanical  subsystem  consists  of  an  accurate  simulation 
of  the  mechanics  of  the  bouncing  balls  and  movable  paddles.  The  system's  sensors  and  actu¬ 
ators  are  also  simulated.  In  addition  to  gready  simplifying  the  system,  simulation  of  the  me¬ 
chanical  subsystem  permits  the  rapid  and  accurate  gathe  3  of  data,  and  permits  the 
straightforward  manipulation  of  interesting  experimental  variables. 

There  are  a  number  of  software  components  which  comprise  the  experimental  environ¬ 
ment.  First  is  the  Alpha  application  program  which  meets  the  given  problem  definition — i.e., 
the  program  must  attempt  to  keep  balls  airborne  by  moving  their  associated  paddles  (the  Al¬ 
pha  scheduling  policy  under  test  is  responsible  for  scheduling  the  threads  involved  in  this  ac¬ 
tivity).  Secondly,  there  is  the  simulator  which  replaces  the  mechanical  subsystem — i.e.,  the 
devices  that  the  program  is  designed  to  control  and  the  physical  environment  in  which  they 
exist.  Finally,  there  is  a  human  experimenter  to  manage  the  experiments  (e.g.,  start  and 
stop  simulation  runs,  alter  simulation  parameters,  etc.). 

2.1  Application  Program  Structure 

The  activities  which  comprise  the  applicauon  program  have  a  variety  of  timeliness  re¬ 
quirements.  The  selection  and  ordering  of  the  activities  executed  is  controlled  by  the  .Alpha 
scheduler.  This  causes  the  effectiveness  of  the  application  program  to  depend  entirely  on  the 
quality  of  the  decisions  made  by  the  scheduler  in  .Alpha.  Because  each  of  the  paddles  in  the 
application  is  assigned  to  a  single  ball,  there  is  a  separate  system  activity  (i.e.,  diread)  as¬ 
signed  to  control  the  movement  of  each  paddle.  Therefore,  when  a  paddle  moves,  the  observ¬ 
er  can  know  that  the  system  activity  responsible  for  the  movement  of  that  particular  paddle 
has  been  scheduled  and  run. 

The  time  constraints  associated  with  threads  .ire  distinguished  from  each  other  in  three 
ways.  The  first  way  is  through  deadline  information  about  the  current  task  (in  this  applica- 


Figure  1:  Experimental  Environment 


tion,  the  time  until  the  assigned  ball  falls  to  the  level  of  the  paddle).  The  second  way  that 
time-critical  activities  are  described  is  by  their  expected  computation  time.  This  estimate  is 
the  amount  of  processing  resources  expected  to  be  required  by  a  thread  in  order  to  meet  a 
time  constraint.  Finally,  there  is  an  integer  value  that  can  be  assigned  by  the  experimenter 
to  each  thread.  This  value  becomes  a  characteristic  known  as  the  importance  of  the  thread. 
In  these  experiments  it  corresponds  to  the  importance  of  the  ball  that  the  thread  is  attempt¬ 
ing  to  keep  aloft.  These  three  characteristics  of  each  paddle  movement  activity  (i.e.,  thread 
time  constraint)  are  provided  by  the  application  program  to  the  Alpha  scheduler.  This  time 
constraint  information  is  provided  so  that  thread  execution  schedules  can  be  created  based 
on  the  time  a  ball  will  take  to  fall  to  the  floor,  the  time  it  will  take  to  move  its  paddle  to  the 
ball  intercept  point,  and  the  value  of  the  ball  to  be  caught.  All  three  of  these  characteristics 
may  be  observed  and  controlled  by  the  experimenter,  so  both  the  basis  of  the  scheduler’s  de¬ 
cisions  and  the  effects  of  the  decisions  themselves  (i.e.,  the  sequence  of  paddle  movements) 
are  directly  visible. 


A-10 


The  Alpha  Operating  System  Scheduler  Evaluation  Experiments 


The  simplicity  of  the  application  limits  the  amount  of  application-level  interference  that 
could  mask  the  effects  of  scheduling  decisions.  A  single  piece  of  application  code  can  de¬ 
scribe  the  correct  operation  every  paddle  activity  in  the  system.  It  is  only  necessary  to  de¬ 
scribe  how,  for  a  single  paddle,  to  use  the  sensor  information  on  the  location  of  the  ball  to 
compute  and  execute  a  sequence  of  paddle  movements  that  will  place  it  in  position  to  inter¬ 
cept  the  falling  ball.  The  only  difference  between  paddle  control  activities  is  the  critical  time, 
expected  computation  time,  and  importance  information  associated  with  each  thread.  The  de¬ 
cisions  about  which  balls  to  (attempt  to)  catch,  and  in  what  order,  are  as  a  result  made  en¬ 
tirely  by  the  Alpha  scheduler. 

The  simulator’s  interface  to  the  application  is  provided  through  the  Sun-L'NIX  remote 
procedure  call  mechanism.  The  simulator  communicates  with  the  application  paddle  manage¬ 
ment  system  to  ensure  that  the  tasks  which  move  the  paddles  are  running  when  the  simula¬ 
tion  is  started,  and  to  remove  them  when  the  simulation  is  stopped  or  the  user  removes  the 
corresponding  ball.  To  remove  or  add  a  paddle,  the  operator  interface  simply  calls  the  corre¬ 
sponding  remote  procedure.  These  remote  procedure  calls  are  translated  into  Alpha  invoca¬ 
tions  by  the  Alpha  external  communications  interface.  Requests  for  simulator  operations 
gin  as  invocations  from  the  application  and  arrive  at  the  simulator  as  remote  procedure  calls. 
The  translations  between  each  of  these  systems  is  provided  by  interfacing  software.  Thus 
an  invocation  of  a  simulator  interface  operation  eventually  is  performed  as  a  remote  proce¬ 
dure  call  on  the  Sun-L’NIX  system,  and  a  remote  procedure  call  of  a  paddle  management  rou¬ 
tine  becomes  an  invocation  on  an  Alpha  testbed  node. 

There  are  two  major  operations  which  tasks  in  the  application  can  request  from  the  simu¬ 
lator.  These  operations  are  GetSensor,  which  returns  information  concerning  the  current  po¬ 
sition  and  velocity  of  a  given  ball,  and  MovePaddle,  which  allows  die  application  to  move  a 
paddle  one  increment  to  the  left  or  right.  MovePaddle  requires  a  fixed  amount  of  node  compu¬ 
tation  time  to  run,  as  would  be  expected  from  an  operation  that  required  die  continuous  puls¬ 
ing  of  a  stepper  motor.  GetSensor  requires  some  time  for  the  data  to  arrive,  so  it  involves 
blocking  and  waiting  for  the  packet  to  arrive.  Both  operations  were  designed  to  model  a 
physical  system.  There  are  .ilso  two  major  operations  that  the  simulator  can  request  the  ap¬ 
plication  to  perform.  These  operations  are  AJdPaddie  and  Removel’addle.  The  application 
has  a  paddle  manager  which  implements  the  paddle  control  operar.oi  s  that  the  simulator  cm 
invoke.  The  paddle  manager  allows  the  evaluation  environment  package  to  rmiotely  create 
and  delete  threads  that  implement  individual  paddles. 

The  implementation  of  the  paddle  manager  depends  on  the  task  management  facilities 
available  on  the  application  system,  as  does  the  implementation  of  anv  auxiliary  modules 
used  to  communicate  with  the  evaluation  environment’s  system.  The  design  of  the  paddle 
tasks,  however,  is  fairly  straightforward  and  is  mostly  independent  of  the  system  on  which 
they  run.  Each  paddle  task  must  query  the  position  and  velocity  of  its  target  bail,  must  calcu¬ 
late  the  predicted  landing  location,  and  must  move  the  paddle  to  that  location.  Once  the  ball 
bounces  or  is  dropped,  the  process  is  repeated.  An  important  fact  to  realize  is  that  the  cyclic 
nature  of  this  task  does  not  make  the  application  a  periodic  process  in  the  sense  of  having 
predictable  time  constraints.  The  timeliness  and  processing  requirements  of  the  paddle  tasks 
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may  be  different  each  time  they  repeat  the  sense -move  loop.  As  in  most  supervisory'  real¬ 
time  problems,  the  workload  cannot  be  predicted  in  advance. 

Two  implementations  of  the  application  were  developed.  These  were  on  a  Sun  UNIX 
system  and  the  Alpha  Release  1  testbed.  The  UNIX  version  was  implemented  to  simplify 
testing  the  application  interface  to  the  simulator.  The  Alpha  system  was  the  object  of  the  ac¬ 
tual  experiments. 

2.1.1  UNIX  Implementation 

The  structure  of  the  UNIX  implementation  is  a  direct  translation  of  the  English  descrip¬ 
tion  given  above.  The  paddle  tasks,  w'hich  are  implemented  with  UNIX  processes,  use  the 
remote  procedure  call  mechanism  to  access  the  simulator  GetSensor  and  MovePaddle  opera¬ 
tions.  Each  paddle  process  calls  GetSensor  to  obtain  the  position  and  velocity  of  the  ball  as 
well  as  the  distance  it  can  move  in  each  paddle  movement  increment  and  the  time  each  move 
takes.  It  then  computes  the  distance  that  it  must  move  to  catch  the  ball  at  the  intercept 
point,  converts  to  the  number  of  movement  increments  that  it  will  require,  and  calls  Move- 
Paddle  that  many  times,  waiting  the  appropriate  delay  between  each  move.  If  the  paddle  ar¬ 
rives  early,  it  uses  the  UNIX  interval  timer  facility  to  block  until  the  intercept  occurs. 

I.iere  were  several  unfortunate  characteristics  of  this  UNIX-based  implementation. 
Probably  the  major  problem  was  that  UNIX,  not  being  a  real-time  system,  had  no  facilities 
for  describing  the  time  constraints  of  a  task.  Each  paddle  task  had  a  time  constraint  which 
was  the  time  required  for  a  ball  to  fall  to  the  level  of  the  paddle,  after  which  there  was  no  use 
in  continuing  to  move  to  the  intercept  point.  There  was  no  way  to  describe  this  time  con¬ 
straint  to  the  system,  and  there  was  no  way  to  tell  the  system  that  such  an  movement  at¬ 
tempt  should  be  aborted  after  it  had  already  failed.  It  was  possible  to  use  the  interval  timer 
facility  and  a  variety  of  complicated  tests  to  generate  the  desired  behavior.  However,  there 
was  no  general,  natural  way  of  describing  the  characteristics  of  the  paddle  tasks  and  having 
them  considered  as  pan  of  the  scheduling  process. 

2.1.2  Alpha  Implementation 

Because  there  are  general  mechanisms  for  describing  time  constraints  in  the  Alpha  sys¬ 
tem,  it  was  straightforward  to  implement  the  paddle  tasks  in  a  way  that  permitted  'hem  to 
describe  their  time  constraints  to  the  scheduling  subsystem.  The  structure  of  he  paddle 
task  remains  much  he  same  from  he  UNIX  version.  However,  he  paddle  task  now  used 
he  information  acquired  from  he  GetSensor  call  to  determine  he  time  required  to  move  he 
paddle  to  he  intercept  point.  The  importance  of  he  task  for  the  purposes  of  the  scheduler  is 
given  by  he  value  of  he  ball  scaled  by  a  constant.  The  value  function  is  given  by  a  constant 
which  drops  to  zero  at  he  time  hat  he  ball  will  pass  he  level  of  he  paddle.  Such  a  time 
constraint  forms  what  is  called  a  hard  deadline. 

Depending  on  he  scheduling  policy  used,  some  or  all  of  this  time  constraint  information 
may  be  utilized  to  determine  a  good  schedule.  Under  policies  that  support  dynamic  dead¬ 
lines,  he  tasks  can  be  automatically  aborted  out  of  heir  deadlines  once  he  deadline  has 
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passed  (this  eliminated  the  elaborate  checking  to  determine  if  the  ball  has  passed  yet).  As 
soon  as  the  ball  is  dropped,  the  deadline  is  aborted. 

2.1  External  Environment  Simulator 

The  external  environment  simulator  serves  as  a  surrogate  for  the  real-world  sensors  and 
actuators  comprising  the  external  environment  of  a  supervisory  control  system.  It  provides 
functions  to  read  the  sensors  and  move  the  actuators,  and  keeps  track  of  the  changes  in  the 
simulated  environment.  A  graphical  operator  interface  allows  the  user  to  control  the  simula¬ 
tion.  These  two  modules  together  allow  the  experimenter  to  manipulate  the  situation  the 
workload  and  record  the  results. 

2.2.1  Simulator  Structure 

The  simulator  models  the  motion  of  the  balls  and  the  paddles  and  provides  sensor  infor¬ 
mation  about  the  current  state  of  both.  The  interface  between  the  evaluation  environment 
and  the  application  was  designed  so  that  the  application  could  be  placed  into  a  real,  physical 
situation  identical  to  that  which  was  being  simulated,  and  no  change  to  the  application  would 
be  necessary.  In  addition  to  modeling  the  motion  of  the  balls,  the  simulator  accepts  requests 
from  the  application  that  cause  the  paddles  to  move.  It  also  accepts  commands  from  the  op¬ 
erator  interface  that  allow  the  user  to  start  and  stop  the  simulation,  create  or  modify  balls, 
and  extract  performance  information  as  the  application  is  running.  Other  actions  performed 
by  the  simulator  include  notifying  the  application  w  hen  a  ball  has  been  dropped. 

The  simulator  performs  most  of  its  work  during  the  simulation  update  period.  This  occurs 
once  every  time  period,  and  involves  updating  the  positions  and  velocities  of  all  the  presently 
existing  balls,  as  well  as  checking  for  collisions  and  performing  bounce  calculations.  These 
computations  are  performed  by  modeling  elastic  collisions  with  the  walls  and  paddles.  To 
better  simulate  the  kinds  of  aperiodic  loads  which  actual  supervisory'  real-time  systems  ex¬ 
perience,  the  bounce  direction  from  a  collision  with  the  paddle  is  selected  randomly.  If  during 
tiie  process  of  updating  the  simulator  state,  it  is  discovered  that  any  balls  have  been 
dropped,  the  application  is  notified  and  directed  to  remove  the  associated  paddle.  However, 
to  enable  the  user  to  sustain  a  constant  load  on  the  system,  it  is  possible,  using  the  operator 
interface,  to  select  certain  bails  that  will  remum  in  the  simulation  when  dropped  and  will 
bounce  back  up  above  the  paddle  instead  of  being  removed  from  the  simulation.  The  output 
of  the  simulator  includes  timestamped  messages  indicating  when  balls  are  caught  or 
dropped,  and  what  the  value  of  each  ball  is.  With  this  information  it  is  possible  to  compute  a 
wide  variety  of  useful  statistics  about  the  performance  of  the  system, 

2.2.2  Operator  Interface 

The  operator  interface  provides  the  experimenter  with  control  over  the  simulation.  It  dis¬ 
plays  a  window  that  contains  a  small  control  panel  for  managing  the  simulation  and  a  huger 
subwindow  that  shows  the  current  simulation  state  (see  Figure  2).  There  are  buttons  on  the 
control  panel  that  permit  the  user  to  stop  and  start  the  simulation.  When  in  the  stopped 
state,  no  paddle  tasks  are  running  on  the  Alpha  system  and  the  user  may  add  or  remove 


Figure  2:  User  Interface 


balls  and  paddles  without  difficulty.  Balls  are  added  or  removed  by  using  two  buttons  re¬ 
served  for  that  purpose.  The  operator  selects  locations  by  “clicking”  the  mouse  button  in 
the  display  area  to  indicate  the  ball  or  the  position  desired.  Adding  or  removing  a  ball  will  re¬ 
sult  in  the  addition  or  removal  of  a  corresponding  paddle.  In  the  stopped  state,  however,  no 
paddles  are  shown;  the  paddles  first  appear  when  the  simulation  is  started.  There  are  also 
facilities  for  capturing  and  replaying  sequences  of  action  that  appear  in  the  display  window, 
as  well  as  for  saving  and  restoring  initial  ball  placements.  Selecting  a  ball  displays  a  panel 
that  allows  the  user  to  alter  its  velocity,  height,  value,  and  paddle  position. 

When  the  user  “clicks”  the  start  button,  the  simulation  begins  and  the  balls  start  moving 
according  to  their  given  initial  conditions.  Once  the  simulation  is  started  the  paddles  start 
moving  10  catch  the  balls.  The  user  may  alter  the  distance  a  paddle  travels  with  a  single 
pulse  of  the  stepper  motor,  the  paddle  speed ,  and  how  much  compute  time  each  pulse  takes, 
the  movement  delay.  With  these  two  controls,  it  is  possible  to  change  the  amount  of  load 
present  on  the  system.  For  example,  increasing  paddle  speed  decreases  the  number  of  com¬ 
putations  required.  Increasing  the  motion  delay  increases  the  computation  time  required. 
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This  ability  to  adjust  the  positions  and  velocities  of  the  balls  and  paddles  greatly  simplifies 
the  task  of  experimenting  w  ith  a  variety  of  loading  conditions. 
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3.  The  Structure  of  an  Alpha  Scheduler 

The  scheduling  function  in  Release  1  of  Alpha  is  managed  by  an  independent  subsystem 
that  executes  on  a  separate  processor.  A  formalized  interface  defines  the  messages  passed 
between  the  Alpha  kernel  and  the  scheduler.  To  simplify  the  development  of  scheduling  poli¬ 
cies,  a  general  framework  for  implementing  policies  has  been  defined.  The  framework  han¬ 
dles  the  actual  message  generation  and  processing,  leaving  the  individual  policy  to  decide 
how  to  respond  to  various  messages. 

The  scheduler  framework  dispatches  each  kind  of  message  from  the  application  processor 
to  a  policy-supplied  handler.  Examples  of  these  messages  include  messages  that  indicate 
that  a  task  should  be  added  to  or  removed,  messages  that  define  how  the  time  constraints  of 
the  currently  running  task  have  changed,  and  others  which  support  the  distributed  nature  of 
Alpha,  including  cleanup  for  certain  aborted  operations.  Each  scheduling  policy  mav  choose 
how  to  respond  to  these  messages  and  how  to  utilize  the  information  provided  therein.  All 
eight  schedulers  which  were  implemented  within  this  framework  required  only  subsets  of  the 
information  provided  by  these  messages,  and  none  needed  any  structure  which  was  not  easi¬ 
ly  created  within  this  framework. 

3.1  Scheduler/Kernel  Interface 

The  function  of  a  scheduler  in  the  Alpha  system  is  to  determine  which  of  the  currently 
ready  threads  to  run.  To  make  this  decision,  the  scheduler  may  use  the  time  constraint  infor¬ 
mation  provided  to  the  scheduler  by  the  application.  This  information  consists  of  three  parts: 
a  rime-value  function ,  indicating  the  time-varying  value  of  completing  a  task  at  a  given  time, 
an  expected  computation  time,  the  cycle  time  required  to  complete  the  task,  and  an  impor¬ 
tance ,  a  value  used  to  scale  the  value  function.  A  scheduling  policy  must  handle  changes  in 
these  thread-provided  parameters  and,  if  necessary,  correctly  reevaluate  the  currently  active 
schedule. 

In  Release  1  of  Alpha,  the  scheduling  subsystem  executes  on  a  separate  processor  from 
the  application  (and  most  of  the  Alpha  kernel).  The  scheduling  framework  implements  a 
queued,  message-based  communication  channel  between  the  processors.  Messages  are 
transmitted  in  two  parts.  There  is  a  command  part,  which  indicates  the  command  to  be  per¬ 
formed,  and  a  body  which  gives  parameters  to  the  command.  The  commands  are: 

•  Add:  used  to  tell  the  scheduler  of  the  presence  of  a  thread  which  is  newly  available 
for  scheduling.  This  can  occur  when  a  new  thread  is  created,  when  a  blocked  thread 
is  unblocked,  or  when  a  thread  from  another  node  Stans  running  on  the  node.  This 
last  variant  is  referred  as  a  “surrogate  add”  because  the  structures  representing 
the  thread  on  this  node  are  acting  as  surrogates  for  the  thread  structure  on  the  node 
where  it  was  created.  There  is  also  a  version  known  as  a  delayed  add',  this  pro¬ 
vides  a  time  delayed  Add  command  and  is  utilized  in  implementing  the  kernel  Sleep 
operation.  The  parameters  describing  the  function  include  a  unique  identifier  for  the 
scheduler  to  refer  to  in  communications  with  the  application  processor.  If  the  Add  is 
a  surrogate  add,  i.e.  if  the  thread  was  created  on  another  node  and  its  point  of  con- 
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trol  has  just  arrived  on  this  node,  the  parameters  include  information  about  the  time 
constraints  it  accumulated  prior  to  arrival  on  this  node. 

•  Remove:  indicates  that  the  current  thread  has  voluntarily  given  up  the  processor. 
This  usually  occurs  when  the  thread  which  is  currently  running  has  blocked  awaiting 
some  activity.  Another  version  called  Kill  is  used  when  the  currently  running  thread 
has  permanently  given  up  the  processor.  This  occurs  when  a  thread  returns  from 
the  invocation  it  started  in,  and  when  a  thread  that  originated  on  another  processor 
completely  finishes  its  work  on  the  node. 

•  Change:  This  command  arrives  when  the  currently  running  thread  has  altered  its 
time  constraints  in  some  way.  There  are  three  ways  m  which  this  can  occur.  First, 
the  thread  may  enter  a  new  deadline.  This  is  referred  as  pushing  time  constraints , 
because  deadlines  may  be  nested.  Second,  the  thread  may  exit  a  deadline.  For 
similar  reasons,  this  is  referred  to  as  popping  time  constraints.  Finally,  the  thread 
can  change  its  importance. 

•  Access  Scheduling  Information:  There  are  four  commands  of  this  type.  They  all 
relate  to  conditions  when  the  time  constraints  must  be  accessed  or  altered  outside 
of  the  normal  stacking  methods.  The  dump  subcommand  is  used  to  gather  a 
thread’s  time  constraints  in  preparation  for  a  remote  invocation.  The  update  com¬ 
mand  is  used  to  update  time  constraint  information  such  as  total  computation  time 
after  the  thread  has  been  executing  on  a  remote  node.  There  are  two  commands 
that  deal  with  abort  conditions  that  permit  the  correct  time  constraints  for  abort  pro¬ 
cessing  to  be  determined.  These  are  the  Get  and  Set  Abort  Scheduling  Information 
commands.  If  a  deadline  aborts,  the  Get  command  is  used  to  determine  the  correct 
time  constraints  to  operate  the  abort  cleanup  code  with.  The  Set  command  is  used 
to  force  the  time  constraints  of  a  specific  thread  into  those  which  are  required  for  its 
abort  processing. 

•  Preemption  Confirmation:  This  is  a  necessary  element  of  the  communication  be¬ 
tween  scheduler  and  kernel.  It  is  sent  after  a  request  to  replace  the  currently  run¬ 
ning  thread  with  another  has  been  successfully  processed.  This  allows  the  schedul¬ 
er  to  update  the  amount  of  time  a  thread  has  run.  There  are  two  variations  of  this 
command,  one  of  which  indicates  that  the  currently  running  thread  was  preempted 
successfully,  and  one  which  indicates  that  the  processor  was  idle  when  the  preemp¬ 
tion  was  requested.  This  message  is  necessary  to  provide  the  scheduler  with  a 
consistent  picture  of  what  is  happening  on  the  application  processor. 

•  Statistics  Control:  There  are  two  of  these  commands,  that  turn  on  and  off  optional 
statistics  gathering,  if  the  current  scheduling  policy  supports  logging. 

There  are  only  a  few  circumstances  in  which  the  scheduler  must  initiate  communications 
with  the  kernel.  Several  of  these  instances  occur  as  pan  of  handshaking  involved  with  the 
scheduler  commands.  Two,  however,  are  of  fundamental  imponance  to  the  operation  of  the 
system.  The  Preempt  command,  which  has  been  previously  discussed,  is  used  to  tell  the 
kernel  to  run  a  specific  thread.  The  Abort  command  is  used  when  the  scheduler  determines 
that  a  thread's  critical  tune  has  passed.  It  initiates  abon  processing  for  the  missed  dead¬ 
line.  This  command  is,  of  course,  only  of  interest  for  policies  that  support  deadlines. 
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3.2  Structure  of  Generic  Scheduler 

Each  of  the  scheduler  commands  described  in  the  previous  section  must  be  implemented 
by  every  scheduling  policy.  The  policy  routines  which  implement  these  commands  are  auto¬ 
matically  called  when  the  commands  are  received.  It  is  possible  to  supply  a  null  function  if 
the  command  is  to  be  ignored  by  the  policy,  or  an  error  function  if  the  command  should  never 
be  received  by  the  policy. 

Each  policy  must  supply  two  types  of  command  handlers.  The  first  kind  is  called  when 
the  command  is  received  under  interrupt,  and  allows  rapid  handling  of  messages  as  well  as 
general  interrupt-level  processing.  In  addition,  the  scheduler  framework  supplies  an  internal 
message  queue  which  may  be  used  to  queue  commands  up  for  foreground  processing  (see 
Figure  3).  The  framework  calls  foreground  procedures  corresponding  to  the  commands  in  the 
queue  as  they  emerge.  Any  part  of  the  handling  for  a  command  may  be  performed  either  un¬ 
der  interrupt  or  in  the  foreground.  If  all  the  commands  are  to  be  handled  in  the  foreground, 
then  the  interrupt  tasks  would  simply  enqueue  the  incoming  commands  into  the  foreground 
queue. 

The  minimum  requirements  for  a  scheduler  in  the  Alpha  system  are  fairly  simple.  The 
scheduler  must  remember  the  set  of  ready  threads,  and  if  the  set  is  non-empty,  make  sure 
that  there  is  always  something  running  on  the  application  processor.  The  scheduler  frame¬ 
work  provides  a  queue  package  which  aids  in  the  manipulation  of  schedules. 
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Scheduling  policies  that  are  more  sophisticated,  generally  share  some  common  character¬ 
istics.  First,  the  schedulers  generally  construct  a  list  describing  the  order  in  which  threads 
should  run.  When  a  thread  is  added  to  the  ready  list  or  the  time  constraints  of  a  thread  are 
changed,  some  computation  is  required  to  determine  whether  or  not  to  reorder  the  list.  The 
operation  of  other  commands,  if  any,  depend  on  how'  the  policy  utilized  the  scheduling  param¬ 
eters  provided  by  the  threads. 
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4.  Scheduling  Policies 

Five  of  the  eight  policies  implemented  for  use  in  the  Alpha  cystem  were  selected  for  eval¬ 
uation  in  these  experiments.  The  following  sections  briefly  describe  the  operation  of  each  of 
these  policies. 

4.1  Round  Robin 

The  Round  Robin  policy  is  the  fairest  of  all  the  schedulers.  It  treats  all  threads  in  the 
system  equally,  giving  each  eligible  thread  the  same  fraction  of  the  processor  time. 

The  implementation  of  the  Round  Robin  policy  is  straightforward.  Every  100ms  a  timer 
event  is  inserted  into  the  queue  by  the  policy  timer  interrupt  routine.  Upon  receipt  of  a  timer 
event,  the  foreground  command  processor  calls  the  timer  routine,  which  removes  the  element 
at  the  head  of  the  queue  and  inserts  n  a*  the  end.  If  the  new  head  is  different  from  the  old 
head,  the  application  processor  is  preempted  with  the  new  head  of  the  queue.  Add  and  Re¬ 
move  commands  are  handled  in  the  simplest  possible  way.  If  the  command  is  an  Add,  the 
new  thread  is  added  at  the  end  of  the  ready  queue.  If  the  command  is  a  Remove,  the  thread 
is  removed  from  the  ready  queue,  and  the  application  processor  is  preempted  with  the  new 
head  of  the  queue.  Under  Round  Robin,  time  constraints  are  ignored,  as  are  the  miscella¬ 
neous  commands  associated  with  accessing  scheduling  information. 

4.2  Static  Priority 

Static  Priority  scheduling  is  the  simplest  method  of  dealing  with  scheduling  parameter  dif¬ 
ferences  between  the  threads  available  to  run.  Each  thread  is  assigned  a  priority  which  is 
equal  to  the  importance  pan  of  its  time  constraint.  The  scheduler  always  selects  the  thread 
with  the  highest  priority,  or  one  of  them,  if  there  are  several  with  the  same  imponance  to 
run.  The  time-cnticality  of  the  thread  not  taken  into  account. 

The  implementation  of  Static  Priority  requires  no  timer  usage.  Ihe  scheduler  frame¬ 
work's  queue  package  incudes  ordered  insertion  routines,  so  the  Add  handler  simply  makes 
an  insertion  into  the  ready  queue,  then  preempts  the  application  processor  if  the  head  chang¬ 
es.  The  Remove  handler  removes  the  thread  and  preempts  with  the  new  head  of  the  queue. 
The  Change  handler  handles  requests  to  change  the  importance  of  threads.  This  change  is 
accomplished  by  removing  the  thread  from  the  queue  and  reinserting  it  with  the  new  impor¬ 
tance.  Again,  if  the  head  of  the  queue  changes,  the  application  processor  is  preempted  with 
the  new  head  of  the  queue. 

4.3  Deadline 

The  Deadline  policy  always  schedules  the  thread  with  the  closest  critical  time.  For  this 
implementation,  the  Deadline  policy  was  extended  to  provide  for  the  abortion  of  deadlines 
that  have  expired.  If  a  thread  misses  a  deadline,  it  is  forced  out  of  the  deadline  section  of 
code  and  begins  executing  a  user-defined  deadline  abort  handler.  If  the  system  has  enough 
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cycles  to  meet  all  of  the  application  deadlines,  the  Deadline  policy  is  optimal — every  time 
constraint  is  satisfied.  If  there  exist  deadlines  which  cannot  be  met,  which  is  what  is  meant 
by  overload ,  then  the  Deadline  policy  may  perform  very  poorly.  For  example,  this  policy  may 
uitempt  to  run  threads  which  cannot  meet  their  deadlines,  but  which  have  early  deadlines. 
The  deadline  policy  is  implemented  as  a  priority  scheme  where  the  time  to  deadline  forms  the 
priority  and  the  head  of  the  queue  is  the  item  with  the  lowest  priority.  However,  the  Dead¬ 
line  policy  uses  the  timer  facilities  to  make  sure  each  thread  is  aborted  when  its  deadline 
passes. 

4.4  Shortest  Processing  Time 

The  Shortest  Processing  Time  policy  considers  only  the  required  computation  time  for 
each  thread.  SPT  always  selects  the  thread  with  the  lowest  remaining  computation  time  to 
run.  It  is  similar  to  Deadline  and  Static  Priority  in  that  it  uses  only  a  single  figure  of  merit  to 
determine  a  schedule.  It  lacks  optimal  behavior  of  Deadline  in  underload,  but  may  perform 
well  under  overload  since  it  is  more  likely  to  pick  threads  which  can  be  performed.  SPT  in 
general  attempts  to  maximize  the  system  throughput  by  completing  as  many  threads  as  pos¬ 
sible  per  unit  time.  SPT  as  implemented  for  Alpha  has  the  automatic  deadline  abort  mecha¬ 
nism  mentioned  above.  The  implementation  of  SPT  is  almost  identical  to  that  of  Deadline, 
except  the  schedule  queue  is  ordered  b;,  the  remaining  processing  time. 

4.5  Best-Effort 

Given  the  problems  with  the  other  schedulers,  which  use  only  a  small  portion  of  the  avail¬ 
able  information  to  construct  a  schedule,  it  is  clear  that  any  superior  scheduling  policies  will 
have  to  make  decisions  based  on  all  the  information  in  the  time  constraints  as  well  as  the  ex¬ 
pected  computation  time.  It  is  known  that  Deadline  scheduling  is  optimal  when  the  system 
is  underloaded.  An  improved  scheduler  can  therefore  use  a  Deadline  scheduling  method 
when  the  system  is  underloaded.  If  the  system  is  overloaded,  the  scheduler  must  decide 
which  threads  not  to  run.  Threads  that  cannot  complete  their  deadlines  are  one  obvious 
choice.  If  that  is  not  sufficient,  the  scheduler  chooses  those  threads  whose  completion  would 
be  the  least  useful  to  the  system.  One  metric  of  utility  to  the  system  is  called  the  value  den¬ 
sity  of  a  thread.  The  Archons  project  has  developed  a  scheduling  policy,  called  the  Best-Ef¬ 
fort  policy,  that  uses  value  density  as  a  metric  when  shedding  load.  Refer  to  [Locke  86]  for  a 
complete  description  of  the  Best-Effort  algorithm. 

The  implementation  of  the  Best-Effort  policy  maintains  a  queue  of  threads  in  deadline  or¬ 
der.  As  each  new  thread  is  inserted,  the  policy  checks  to  see  if  overload  has  been  reached. 
When  overload  is  reached,  the  policy  sheds  load  by  removing  the  least  valuable  threads  until 
the  system  is  no  longer  overloaded. 
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5.  Experimental  Results 

This  chapter  describes  the  experiments  performed  on  the  chosen  scheduling  policies  and 
their  results.  Justification  is  provided  for  the  particular  experiments  that  were  performed,  and 
the  results  of  the  experiments  are  presented. 

5.1  Experimental  Design 

The  goal  of  these  experiments  was  to  develop  an  understanding  of  the  behavior  and  per¬ 
formance  of  the  schedulers  described  in  the  preceding  chapter.  The  experiments  performed 
provide  a  broad  range  of  quantitative  information  about  each  of  the  schedulers  used.  By  vary¬ 
ing  the  loading  conditions  and  analyzing  the  resulting  data,  many  different  metrics  could  be 
extracted  to  compare  the  policies. 

5.1.1  Load  Generation 

It  is  possible  to  increase  or  decrease  the  number  of  threads  in  the  application,  by  chang¬ 
ing  the  number  of  balls  in  the  scenario.  Having  a  large  number  of  threads  tends  to  make  the 
tests  more  accurate  since  small  variations  in  the  behavior  of  the  threads  have  less  of  an  ef¬ 
fect  on  the  large-scale  behavior  of  the  application.  With  more  threads  it  is  easier  to  ensure 
that  the  scheduling  policy  being  tested  always  has  ready  threads  to  choose  from,  thus  im¬ 
proving  the  quality  of  the  information  extracted  from  the  test. 

The  loading  characteristics  are  also  affected  by  the  initial  state  of  the  balls  and  paddles. 
It  is  possible,  but  in  general  not  desirable,  to  cause  the  conditions  at  the  start  of  the  simula¬ 
tion  to  be  more  or  less  favorable  by  placing  the  paddles  farther  away  or  closer  to  the  balls 
they  are  catching,  increasing  the  velocity'  of  the  balls,  etc.  This  type  of  testing  was  done  to 
analyze  individual  decisions  made  by  each  policy  as  an  aid  to  understanding  their  behavior, 
but  is  detrimental  to  observing  long-term  effects  since  it  introduces  start-up  transients  that 
obscure  the  steady-state  performance. 

There  are  two  ways  to  increase  or  decrease  the  computation  time  required  by  each  thread 
in  the  system.  The  first  method  is  to  change  the  paddle  speed.  Increasing  the  paddle  speed 
reduces  the  number  of  times  each  thread  consumes  a  block  of  processor  cycles.  Decreasing 
the  paddle  speed  has  the  opposite  effect.  The  other  way  to  change  the  computation  time  is 
to  alter  the  movement  delay.  Increasing  this  parameter  will  result  in  increased  computation 
by  each  thread  since  more  effort  is  required  to  move  the  paddle  each  step  on  its  way  to  the 
intercept  point. 

5.1.2  Evaluation  Metrics 

There  are  several  factors  which  must  be  considered  in  order  to  make  a  fair  comparison  be¬ 
tween  scheduling  policies.  The  different  policies  have  implementations  which  may  vary-  con¬ 
siderably  from  that  which  may  be  optimally  attained.  Thus,  it  is  important  to  factor  out  the 
various  problems  that  are  due  only  to  the  implementation  of  the  policy.  The  primary  factor 
which  affects  the  apparent  performance  of  the  schedulers  is  the  fact  that  some  schedulers 
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may  take  longer  to  provide  a  thread  for  the  application  to  run  after  the  currently  running 
thread  blocks.  This  effect  is  primarily  realized  in  the  system  throughput,  resulting  in  an  ap¬ 
parently  faster  application.  Part  of  the  data  collected  is  a  measure  of  the  system  throughput, 
the  total  number  of  paddle  movements  accomplished  in  each  minute.  It  is  possible  to  utilize 
this  throughput  measure  to  normalize  all  of  the  schedulers  to  a  common  measure,  which  was 
selected  to  be  the  value  to  the  system  accomplished  by  the  Round  Robin  scheduler.  To  de¬ 
termine  the  normalized  value  to  the  system  obtained  by  a  given  scheduler,  it  is  only  neces¬ 
sary  to  divide  by  the  throughput  measure  of  the  policy  and  multiply  by  the  throughput  mea- 
>ure  of  Round  Robin.  Ln  other  words,  the  data  is  interpreted  as  though  it  came  from  a  sched¬ 
uler  which  had  the  throughput  of  Round  Robin,  but  made  different  decisions.  This  enables  the 
examination  of  the  decisions  made  by  the  scheduler  independent  of  the  qualify  of  the  policy 
implementation. 

The  time-value  curve  of  a  system  activity  is  composed  of  information  on  how  the  comple¬ 
tion  value  of  a  segment  of  code  vanes  with  time.  In  combination  with  the  importance,  it  can 
provide  the  scheduler  with  knowledge  of  how  much  value  the  system  would  accrue  from  the 
computation  if  the  activity  was  scheduled  at  a  certain  time.  A  scheduling  policy  should  in 
theory  be  able  to  determine  the  most  valuable  schedule  possible  from  this  information.  How¬ 
ever,  some  policies  use  only  subsets  of  this  information,  and  use  the  information  in  different 
w'ays,  and  thus  may  create  other  schedules  of  varying  worth.  The  aggregate  value  to  the 
system  created  by  each  scheduling  policy's  allocation  of  computing  cycles  is  the  primary  met¬ 
ric  used  to  compare  policies  in  this  report.  Thus  the  main  criteria  we  will  use  as  a  metric  to 
compare  scheduling  policies  is  the  extent  to  which  each  policy  maximizes  the  value  provided 
to  the  system  by  the  application.  This  is  the  logical  basis  on  which  to  judge  schedulers, 
since  a  scheduling  policy  is  intended  to  translate  as  best  as  possible  the  characteristics  of 
each  thread  into  a  good  schedule  for  the  system.  Since  the  set  of  characteristics  provided  by 
threads  in  Alpha  is  the  completion  value  as  a  function  of  time,  then  the  ideal  scheduler  is  one 
that  selects  the  schedule  that  provides  the  greatest  value.  Over  long  periods  of  time,  the 
better  policies  will  provide  mere  value  to  the  system  than  inferior  ones. 

The  second  major  metric  used  to  compare  policies  is  the  percentage  of  the  time  con¬ 
straints  met  by  each  policy.  This  metric  is  of  secondary  importance  since  maximizing  the 
number  of  met  tune  constraints  does  not  necessarily  maximize  the  value  obtained  for  the 
system.  Nevertheless,  it  may  provide  clues  as  to  why  different  policies  perform  as  they  do. 

5.2  Behavior  Analysis 

To  understand  why  each  scheduling  policy  behaves  as  it  does,  it  is  helpful  to  examine 
some  specific  scheduling  scenarios  and  to  analyze  how  each  of  the  schedulers  would  respond. 

The  first  scenario  of  interest  is  one  where  all  the  balls  may  be  caught,  but  only  if  a  certain 
sequence  is  followed.  This  condition  is  shown  in  Figure  4.  In  this  picture,  ball  A  takes  long¬ 
er  to  return  to  the  intercept  level  than  ball  B.  Static  Priority  will  fail  in  this  case  since  ball  B 
bounces  twice  for  every  single  bounce  of  ball  A.  If  one  were  to  assign  a  higher  priority  to  ball 
A,  ball  A  would  always  be  caught  first  and  ball  B  would  be  missed  on  its  second  bounce.  If 
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Figure  4:  Dynamic  Priority  Example 


Figure  5:  Inverted  Deadline/Value  Example 


one  were  to  assign  a  higher  priority  to  ball  B,  A  w-ould  be  missed.  Both  Deadline  and  Best- 
Effort,  on  the  other  hand,  would  catch  ball  A,  then  ball  B  twice,  then  ball  A  again.  SPT  w'ould 
give  a  higher  priority  to  catching  B,  which  takes  less  computation  time,  and  so  would  work 
exactly  like  Static  Priority  when  the  higher  priority  is  given  to  ball  B. 
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Another  underload  scenario  is  shown  in  Figure  5.  There  are  four  balls  with  values  1 
through  4.  The  value  4  ball  is  farthest  from  its  intercept  point  and  value  1  ball  is  the  nearest. 
The  paddle  assigned  to  each  ball  is  one  time  unit  away  from  its  intercept  point  and  each  ball 
is  as  many  time  units  away  from  the  intercept  point  as  its  value.  In  this  case,  the  urgency  of 
each  computation  is  the  inverse  of  the  importance  of  the  computation  (i.e.,  the  higher  the  val¬ 
ue  of  the  ball,  the  less  urgent  it  is  to  catch  it).  Static  Priority  will  fail  badly  on  this  scenario. 
It  will  first  move  to  intercept  the  value  4  ball,  thus  dropping  the  value  1  ball.  It  will  then 
move  to  intercept  the  value  3  ball  and  drop  the  value  2  ball.  Static  Priority  will  successfully 
catch  the  balls  of  value  3  and  4,  but  will  drop  those  with  value  1  and  2.  Both  Deadline  and 
Best-Effort  will  catch  all  of  the  balls  in  this  scenario,  while  SPT  will  act  in  random  order  (all 
the  paddles  take  one  time  unit  to  move  into  position). 

The  next  case  of  interest  is  one  where  it  is  not  possible  to  catch  all  of  the  balls  (Figure 
6).  The  value  5  ball  is  three  time  units  away  from  the  intercept  point,  as  is  its  paddle.  The 
value  3,  2  and  1  balls  are  also  each  three  time  units  away  from  their  respective  intercept 
points;  but  their  paddles  are  each  one  time  unit  away  from  the  intercept  point.  Static  Priority 
would  successfully  catch  the  value  5  ball,  dropping  balls  of  value  3,  2,  and  1  in  the  process. 
Best-Effort  would  recognize  the  overload  situation  and  abort  the  catching  of  the  value  5  ball 
in  favor  of  catching  the  value  1,  2,  and  3  balls  that  provide  more  value  to  the  system.  Dead¬ 
line  would  catch  two  of  the  three  smaller  value  balls,  then  select  randomly  between  moving 
one  time  increment  toward  the  value  5  ball  (which  now  cannot  be  caught)  or  catching  the 
third  small  ball.  SPT  would,  in  this  case,  successfully  catch  the  three  small  balls,  because 
they  all  require  fewer  computational  resources  to  complete. 
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Another  interesting  scenario  is  shown  in  Figure  7.  This  figure  represents  another  over¬ 
load  situation.  All  three  balls  will  arrive  at  their  intercept  points  at  the  same  time  (two  time 
units).  Each  of  the  paddles  is  only  one  time  unit  away  from  their  intercept  points.  Both 
Best-Effort  and  Static  Priority  will  select  the  value  7  and  9  balls,  while  both  SPT  and  Dead¬ 
line  will  select  randomly  (all  have  the  same  deadline  and  computation  time). 

Finally,  there  is  the  case  in  which  one  ball  is  completely  impossible  to  catch.  Such  a  sce¬ 
nario  is  shown  in  Figure  8  where  a  ball  of  value  3  is  one  unit  of  time  from  us  intercept  point, 
while  its  paddle  is  two  time  units  away.  There  is  another  ball  of  value  1  which  is  one  unit  of 
time  away  from  the  intercept  point,  as  is  its  paddle.  Static  Priority  will  try  to  catch  the  un- 
catchable  ball  of  value  3  while  disregarding  the  catchable  value  1  ball.  Best-Effort  will  abort 
the  paddle  of  the  value  3  ball  since  its  deadline  cannot  be  made,  and  will  catch  the  value  1 
ball.  Deadline  will  choose  randomly  between  the  two  balls  (which  have  the  same  dead¬ 
lines).  SPT  will  catch  the  ball  of  value  1  since  it  requires  less  computation  time. 

These  scenarios  indicate  that  the  Best-Effort  policy  behaves  will  in  a  variety  of  different 
loading  conditions.  Unlike  other  policies  which  may  perform  well  in  a  limited  domain,  the 
Best-Effort  policy  uses  the  full  information  available  in  the  time-value  function  specifications 
to  intelligently  schedule  tasks  in  both  underload  and  overload  situations. 
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Figure  8:  Impossible  Time  Constraint 
5.3  Simulation  Results 

Several  metrics  for  long-term  performance  were  collected  from  each  scheduler.  The  first 
measure  examines  how  sensitive  each  scheduler  was  to  variations  in  thread  importance  (i.e., 
ball  value).  The  second  metric  records  how  successful  each  of  the  scheduling  policies  was  at 
meeting  the  application  time  constraints  (in  terms  of  percentage  of  time  constraints  satis¬ 
fied).  The  final  indicator  combines  both  ball  value  and  time  constraint  measures  to  judge  the 
overall  performance  of  each  policy. 

5 3.1  Thread  Importance  Sensitivity 

As  may  be  seen  from  the  graphs  of  percent  caught  versus  ball  value  (shown  on  the  fol¬ 
lowing  pages),  each  scheduler  has  a  characteristic  form  indicating  the  trade-offs  it  makes 
when  catching  balls  of  different  values.  Round  Robin,  for  example,  has  a  flat  graph  (Figure  9) 
indicating  that  it  does  not  distinguish  between  threads  based  on  their  value.  Each  thread  in 
the  system  receives  the  same  fraction  of  the  available  processor  cycles.  As  expected,  in¬ 
creasing  the  paddle  speed  increases  the  application’s  ability  to  catch  balls.  The  Deadline  al¬ 
gorithm  (Figure  10)  is  also  not  responsive  to  ball  value  and  shows  similar  behavior. 

The  Shortest  Processing  Time  algorithm  (Figure  11),  which  also  disregards  thread  impor¬ 
tance,  shows  some  sharp  differences  between  ball  values.  This  effect  is  due  to  the  particu. or 
way  in  which  the  application  interacts  with  this  scheduling  policy.  The  amount  of  movement, 
and  thus  the  compute  time,  needed  to  catch  a  given  ball  often  increases  after  the  ball  is 
missed.  The  paddle  needs  to  move  farther  to  make  the  next  catch,  has  a  greater  required 
computation  time,  will  thus  be  less  likely  to  be  scheduled,  and  so  also  less  likely  to  catch  the 
ball.  If,  on  the  other  hand,  the  paddle  catches  the  ball,  it  will  be  closer  to  the  intercept  point 
for  the  next  catch,  will  require  less  computation  time,  will  be  more  likely  to  be  scheduled,  and 
will  be  more  likely  to  again  catch  the  ball.  Thus,  balls,  once  caught,  are  likely  to  continue  be¬ 
ing  caught.  Once  dropped,  they  are  likely  to  continue  being  dropped.  Therefore  each  ball  will 
tend  to  either  be  caught  well  or  caught  poorly  for  most  of  each  run.  This  explains  why  the 
SPT  algorithm  shows  such  a  wide  variation  in  catching  percentages  with  respect  to  ball  val¬ 
ue.  Most  applications  do  not  exhibit  this  type  of  behavior. 
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Figure  11:  SPT  Percent  Caught 


Figure  12:  Static  Priority  Percent  Caught 
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Figure  13:  Best-Effort  Percent  Caught 

Static  Priority  (Figure  12)  has  a  very  low  catch  rate  for  the  small  value  balls,  jumping  to 
an  almost  perfect  rate  balls  of  higher  values.  Static  Priority  scheduling  always  runs  the  most 
important  threads  First.  It  therefore  catches  the  high  value  balls  (if  it  can),  then  attempts  to 
catch  the  next  highest  value  balls,  etc.  Increasing  the  paddle  speed  enables  the  application 
to  catch  more  of  the  top  value  balls. 

The  characteristic  curve  for  the  Best-Effort  policy  (Figure  13)  is  smoother  than  those  for 
the  other  policies.  Like  Static  Priority,  Best-Effort  has  a  very  good  catching  rate  for  the  high¬ 
est  value  balls.  However,  the  rate  of  decrease  between  the  high  value  balls  and  the  lower 
value  balls  is  more  continuous.  This  behavior  is  a  very  important  characteristic  of  the  Best- 
Effort  scheduler.  Instead  of  concentrating  only  on  the  highest  value  balls,  it  tries  to  catch  the 
combination  of  balls  that  maximizes  the  total  value  to  the  system.  It  may  often  be  possible 
to  schedule  the  successful  capture  of  several  balls  of  low  value  in  place  of  a  single  one  of 
higher  value,  and  as  a  result  provide  better  total  value  to  the  system.  Compared  to  Static 
Priority’s  insistence  on  catching  high  valued  balls  to  the  exclusion  of  others,  this  selection 
can  result  in  a  considerable  increase  in  the  value  obtained. 

5.3.2  Meeting  Application  Time  Constraints 

One  important  method  of  comparing  the  schedulers  is  to  examine  how  well  each  of  them 
meets  the  thread  deadlines,  i.e.  what  fraction  of  the  balls  are  successfully  caught.  The  ratio 
of  balls  caught  to  the  total  number  of  potential  catches  is  shown  for  each  scheduler  as  a  func¬ 
tion  of  paddle  speed  in  Figure  14.  As  expected,  the  ability  of  any  scheduler  to  meet  dead¬ 
lines,  and  thus  to  catch  balls,  increases  with  paddle  speed.  It  is  interesting  to  note  that  the 
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Deadline  policy  fares  very  poorly  on  this  experiment.  Since  the  system  is  heavily  overloaded 
(all  percentages  are  <100%),  Deadline  scheduling  may  waste  significant  time  attempting  to 
meet  impossible  time  constraints.  The  SPT  policy  performs  well  since  it  concentrates  on 
tasks  which  are  easily  accomplished.  The  Best-Effort  policy  performs  as  well  as  or  better 
than  any  of  the  other  policies  because  of  its  intelligent  overload  handling. 

5.3.3  Maximizing  Application  Value 

The  total  value  metric  is  determined  by  dividing  the  value  of  the  balls  caught  by  the  value 
that  would  have  been  obtained  if  all  of  the  balls  were  always  caught.  Figure  15  illustrates 
the  performance  of  each  scheduling  policy  using  this  measure. 

It  is  worthwhile  to  compare  Figure  14  and  Figure  15  (the  two  graphs  are  extracted  from  the 
same  experimental  data).  The  scheduling  policies  that  ignore  thread  importance— Round 
Robin,  Deadline,  and  SPT — catch  almost  the  same  percentage  of  balls  as  they  do  of  value 
(their  curves  are  practically  identical  in  the  two  graphs).  The  two  policies  that  consider 
thread  importance — Static  Priority  and  Best-Effort — catch  more  valuable  balls  and  are  shift¬ 
ed  up  by  approximately  10%  in  the  graph  that  indicates  the  percentage  of  the  total  value 
caught  (Figure  15). 

The  policies  that  performed  the  worst  using  the  value  metric,  Round  Robin  and  Deadline, 
are  also  the  schedulers  that  did  the  worst  job  of  meeting  time  constraints.  Clearly  they 
achieve  less  value  to  the  system  simply  because  they  catch  fewer  balls.  The  Shortest  Pro¬ 
cessing  Time  scheduler  achieves  the  next  highest  value  to  the  system.  It  performs  better 
than  Round  Robin  and  Deadline  because  it  catches  more  bails,  but  it  does  worse  than  Static 
Priority  and  Best-Effort  because  it  ignores  value.  Static  Priority  and  Best-Effort  are  the 
most  successful  and  are  similar  in  performance  for  this  particular  set  of  experiments. 

Static  Priority  and  Best-Effort,  are  worthy  of  further  consideration.  One  reason  they  per¬ 
form  well  is  that,  unlike  the  other  schedulers,  value  information  plays  an  important  part  in 
scheduling  decisions.  One  might  wonder  why  Static  Priority,  which  does  not  consider  time 
constraints,  is  so  successful  at  accruing  value?  The  answer  is  found  by  examining  how  Static 
Priority  distributes  cycles  to  an  arbitrary  mix  of  threads.  In  overload,  only  the  highest  impor¬ 
tance  threads  run  (excluding  all  others)  regardless  of  how  likely  their  time  constraints  are  to 
be  met.  In  the  short  term,  this  may  result  in  more  dropped  balls.  If  a  thread's  ability  to  meet 
an  individual  time  constraint  were  independent  of  its  past  history,  this  behavior  would  result 
in  a  poor  long-term  performance  as  well.  However,  if  expendmg  cycles  on  a  time  constraint, 
even  if  the  constraint  is  not  satisfied,  serves  to  improve  the  chances  of  meeting  the  next  time 
constraint  a  thread  establishes,  then  the  cycles  are  not  wasted  and  may  benefit  the  system 
in  the  long  term.  This  effect  manifests  itself  in  this  application.  If  a  scheduler  concentrates 
solely  on  the  highest  value  balls,  some  bails  that  could  have  been  caught  may  be  dropped. 
However,  because  they  are  receiving  the  majority  of  the  processing  cycles,  the  high  value 
balls  will  tend  to  be  the  ones  which  are  the  easiest  to  catch.  As  a  result,  scheduling  deci¬ 
sions  which  appear  to  be  bad  based  on  die  available  information  may  be  good  in  the  long 
term.  Some  applications  do  exhibit  this  type  of  “feedback;"  however,  the  majority  of  tasks 
have  a  greater  independence  between  activations. 
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Figure  16:  Percent  of  Value  Caught  w  ith  Random  Replacement 


Figure  17:  Percent  of  Value  Caught  with  Smaller  Value  Variance 
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To  study  the  behavior  of  independent  tasks,  a  second  series  of  experiments  was  per¬ 
formed.  The  application  was  altered  so  that  after  balls  are  caught  or  dropped  they  move  to  a 
random  point  in  the  air  and  begin  falling  again.  Therefore,  cycles  spent  on  an  unsuccessful 
catch  is  time  poorly  spent.  A  bad  short-term  decision  cannot  in  general  be  converted  into  a 
good  long-term  one.  The  results  of  this  modification  are  shown  in  Figure  16. 

Another  point  to  consider  is  whether  the  choice  of  values  for  the  eight  balls  has  an  effect 
on  the  performance  of  the  two  schedulers  that  consider  thread  importance.  The  original  set  of 
eight  bails  valued  one  through  eight  was  replaced  by  three  balls  of  value  six  and  five  of  value 
five.  The  results  are  shown  in  Figure  17.  The  comparative  performance  of  the  Best-Effort 
policv  improves  with  this  change  in  value  distribution.  The  key  to  understanding  this  relative 
improvement  in  Best-Effort's  performance  is  the  fact  that  the  balls  with  the  highest  value 
are  no  longer  so  useful  to  the  system  that  focusing  on  them  to  the  exclusion  of  others  is  prof¬ 
itable. 
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6.  Conclusions 

The  best  scheduler  for  a  particular  application  would  often  be  one  designed  precisely  to 
match  the  requirements  of  the  system.  Such  a  scheduler  could  have  complete  knowledge  of 
the  application  and  could  exploit  application-specific  information  to  achieve  the  best  possible 
performan;e.  For  certain  low-level  systems  where  there  are  few  different  types  of  activities 
or  where  the  events  occurring  in  the  system  are  completely  predictable,  custom  schedulers 
may  be  feasible.  As  the  variety  of  time  constraints  and  frequency  of  unexpected  events  in¬ 
creases,  however,  it  becomes  more  and  more  difficult  to  construct  an  application-specific 
scheduler  that  will  operate  correctly. 

Since  building  a  custom  scheduler  for  each  application  is  impractical,  scheduling  policies 
have  been  developed  that  utilize  application-specified  hints  or  requirements  information  to 
schedule  activities  in  the  way  that  will  most  benefit  the  application.  In  general,  the  more  in¬ 
formation  given  to  the  scheduler,  the  better  the  scheduling  decisions  can  be.  One  conse¬ 
quence  of  using  additional  information  is  that  scheduling  decisions  may  become  more  com¬ 
plex.  It  is  therefore  necessary  to  balance  the  complexity  of  the  scheduling  operations  with 
the  resulting  improvement  in  the  application  performance. 

In  the  scheduling  policies  tested  in  this  work,  the  amount  of  application-specified  informa¬ 
tion  used  to  make  scheduling  decisions  varied  from  none  (Round  Robin)  to  a  complete  time- 
value  function  (Best-Effort).  Predictably  enough,  it  was  the  scheduler  that  used  the  most  in¬ 
formation  about  the  application,  Best-Effort,  that  showed  the  best  behavior.  The  tests  indi¬ 
cate  that  the  extra  computation  time  required  in  the  Best-Effort  algorithm  was  small  enough 
to  make  the  Best-Effort  scheduling  policy  a  good  balance  between  performance  and  computa¬ 
tional  complexity. 
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1.  Introduction 

Previous  real-time  scheduling  research  has  primarily  addressed  simple  tasks  and  has  not 
considered  that  time -constrained  activities  may  span  multiple  nodes  in  a  distributed  system 
and  may  have  multiple,  nested  timeliness  requirements.  This  research  will  investigate  how' 
limited  additional  information  (relative  to  current  algorithms)  about  the  execution  require¬ 
ments  of  these  composite  real-time  activities  can  be  used  to  improve  the  quality  of  schedul¬ 
ing  decisions  made  at  each  node  in  a  distributed  system. 

1.1  Application  Domain 

There  are  several  classes  of  real-time  systems  [Bennett  88].  This  work  considers  a 
class  known  as  supervisory  real-time  systems.  Typical  applications  of  this  type  include  in¬ 
dustrial  factory  automation  (e.g.,  automobile  manufacturing),  platform  management  (e.g., 
space  stations),  and  military  command  and  control  (e.g.,  air  defense).  These  systems  must 
operate  correctly  in  highly  dynamic  environments  where  requirements  and  resources  may 
vary  gradually  or  may  change  suddenly  without  warning.  Often,  the  applications  execute  on 
distributed  computer  systems  where  processing  nodes  are  physically  separated  to  reflect  the 
structure  of  the  problem  or  to  enhance  availability  and  survivability. 

Supervisory  real-time  systems  differ  from  low-level  sampled  data  monitoring  and  control 
systems  in  several  significant  ways.  Unlike  low-level  systems  which  consist  primarily  of 
simple  periodic  tasks,  supervisory  real-time  systems  manage  a  wide  range  of  complex  activi¬ 
ties.  These  activities  are  characterized  by  the  following  features: 

•  Activities  have  stochastic  arrival  and  execution  times.  It  is  often  difficult  or  impossible 
to  predict  when  or  how  often  activities  will  be  initiated. 

•  Activities  may  have  a  variety  of  critical  timeliness  requirements  including  hard  dead¬ 
lines,  which  indicate  that  an  activity  must  be  completed  within  a  specific  time  interval 
for  its  result  to  be  useful,  and  “softer"  time  constraints,  which  describe  activities  for 
which  the  value  of  completing  the  work  varies  across  time. 

•  Activities  are  often  composed  of  several  execution  stages  which  may  involve  computa¬ 
tion  on  several  different  nodes  in  the  system. 

•  Individual  activities  may  have  multiple  nested  timeliness  requirements  imposed  by  dif¬ 
ferent  levels  of  the  application  environment. 

We  call  this  class  of  activities  which  may  have  multiple  execution  stages  and  nested  timeli¬ 
ness  requirements  composite  activities. 
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Composite  Activities:  An  Example 

Consider  an  automated  toy  factory.  The  factory  contains  several  robots — some  of  which 
are  equipped  for  a  variety  of  tasks  and  some  of  which  are  specialized  for  certain  duties.  The 
movement  of  each  robot  is  directed  by  a  local,  low-level  control  system.  These  low-level 
controllers  are,  in  turn,  operated  by  a  distributed  supervisory  real-time  system  that  is  re¬ 
sponsible  for  coordinating  the  robots  and  for  guiding  overall  production. 

Among  other  things,  the  factory  produces  toy  fire  trucks.  The  individual  components  for 
the  trucks  (chassis,  body,  fire  ladder,  and  tires)  are  fabricated  at  another  site  and  brought  to 
the  automated  factory  for  assembly.  The  steps  in  assembling  a  truck  are:  1 )  attaching  the 
ladder  to  the  body,  2)  applying  glue  to  the  chassis,  3)  joining  the  body  with  the  chassis,  and 
4)  attaching  the  wheels.  One  type  of  robot  is  responsible  for  attaching  the  ladder  and  gluing 
the  body  and  chassis  together,  while  a  second  robot  is  specialized  for  attaching  the  wheels. 
Because  of  its  special  input/output  requirements,  the  wheel  robot  is  controlled  by  a  separate 
processing  node. 

The  assembly  of  each  fire  truck  is  controlled  by  a  single  high-level  activity  in  the  distrib¬ 
uted  control  system.  In  general  (although  it  may  vary  with  demand),  the  assembly  of  a  truck 
should  be  completed  in  four  minutes.  After  directing  the  main  assembly  robot  to  pick  up  the 
appropnate  parts  and  attach  the  ladder,  the  robot  is  instructed  to  apply  glue  to  the  chassis. 
It  is  best  to  let  the  glue  to  dry  for  30  seconds  before  joining  the  parts.  The  drying  time  allows 
the  glue  to  become  “tacky,”  reducing  the  chance  of  a  defective  bond.  Because  glue  starts 
drying  as  soon  as  it  is  applied,  it  is  also  important  to  join  the  body  to  the  chassis  within  a 
certain  time.  Otherwise,  the  truck  may  fall  apart.  While  it  is  best  if  the  parts  are  joined  with¬ 
in  60  seconds,  it  is  acceptable  to  wait  as  long  as  90  seconds.  The  penalty  for  waiting  is  that 
more  defective  trucks  may  be  produced,  potentially  reducing  profits.  If  more  than  90  seconds 
elapse,  the  partially  completed  truck  is  discarded.  Once  the  truck  chassis  is  assembled,  it  is 
passed  to  the  second  robot  which  attaches  the  wheels. 

When  one  or  more  of  the  robots  is  broken  or  demand  for  the  trucks  is  high,  the  assembly 
timing  requirements  are  adjusted  to  reduce  the  glue  drying  time  and  reduce  the  overall  time 
allowed  for  completing  the  assembly. 

The  truck  assembly  activity  has  several  significant  features.  First,  it  consists  of  multiple 
stages  (i.e.,  attaching  the  ladder,  applying  the  glue,  joining  the  body  to  the  chassis,  and  at¬ 
taching  the  wheels)  and  involves  processing  on  more  than  one  node.  Second,  it  involves  a 
time -constrained  assembly  stage  (gluing  and  joining)  which  has  a  hard  cut-off.  This  con¬ 
straint,  however,  is  not  a  classical  hard  deadline  since  an  interval  of  decreasing  utility  pre¬ 
cedes  the  cut-off  time.  Third,  the  time  constraint  for  joining  the  chassis  and  body  is  nested 
within  a  higher  level  timeliness  requirement  that  specifies  the  total  assembly  time  for  the 
truck.  Finally,  the  system  load  and  timeliness  requirements  may  change  because  of  in¬ 
creased  demand  or  equipment  failures. 
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Because  of  the  potentially  complex  and  dynamic  nature  of  activities  and  their  time  con¬ 
straints,  effective  processor  scheduling  for  supervisory  real-time  systems  is  very  difficult. 
The  scheduling  problem  is  further  complicated  by  the  requirement  that  the  systems  cope 
gracefully  with  both  transient  and  permanent  overloads  caused  by  changes  in  the  environ¬ 
ment  (e.g.,  alarm  conditions)  or  by  reductions  in  the  available  resources  (e.g.,  node  failures). 
The  goals  for  scheduling  resources  under  these  conditions  can  be  summarized  as  follows: 

•  When  sufficient  resources  are  available,  activities  should  be  scheduled  in  such  a  way 
that  their  timeliness  requirements  are  satisfied. 

•  When  the  system  is  overloaded,  activities  should  be  temporarily  removed  from  the 
schedule  so  that  the  timeliness  requirements  of  activities  that  do  execute  will  be  satis¬ 
fied.  Further,  the  scheduler  should  choose  activities  to  execute  so  that  the  ones  select¬ 
ed  will  be  the  most  beneficial  to  the  application. 

The  above  goals  are  distinct  in  several  ways  from  those  often  suggested  for  low-level  re¬ 
al-time  systems.  In  particular,  these  goals  consider  both  the  timeliness  requirements  and 
the  relative  value  of  different  activities  in  describing  how  scheduling  deci  or/  should  be 
made.  The  goals  also  recognize  that  activities  with  soft  time  constraints  may,  in  some  cir¬ 
cumstances  (e.g.,  alarm  conditions),  be  more  valuable  to  the  application  than  those  with  hard 
deadlines. 

1.2  Related  Work 

Much  of  the  previous  real-time  scheduling  research  is  based  on  different  assumptions 
about  the  application  environment  and  the  associated  scheduling  requirements.  Many  re¬ 
searchers  have  considered  systems  where  the  workload  is  very  predictable.  Other  work  has 
concentrated  on  trying  to  guarantee  hard  deadlines  under  normal  conditions — often  at  the  ex¬ 
pense  of  proper  overload  handling.  The  research  which  has  investigated  more  flexible  over¬ 
load  handling  does  not  address  the  composite  nature  of  activities  and  was  not  designed  for 
distributed  environments. 

A  significant  amount  of  research  has  explored  the  use  static  priority  assignments  to  meet 
the  real-time  requirements  of  an  application.  Liu  and  Layand  [Liu  7?]  described  a  technique 
known  as  rate  monotonic  scheduling  in  which  static  priorities  are  used  to  schedule  periodic 
tasks  that  have  hard  deadlines.  In  [Sha  86]  the  technique  of  period  transformation  is  sug¬ 
gested  as  a  method  of  achieving  better  overload  behavior  in  these  penodic  systems.  Lehocz- 
ky,  Sha,  and  Strosnider  ([Lehoczky  87],  (Strosnider  88])  have  explored  how  server  tasks 
can  be  used  in  a  rate  monotonic  environment  to  provide  fast  service  for  apenodic  tasks  that 
do  not  have  explicit  time  constraints.  This  work  has  been  extended  in  [Sprunt  88]  to  consid- 
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er  aperiodic  tasks  with  hard  deadlines.  Rate  monotonic  scheduling  has  also  be  used  as  the 
basis  for  work  at  the  University  of  Illinois  ([Lin  87],  [Liu  87],  [Chung  88]),  where  research¬ 
ers  have  considered  methods  for  scheduling  computations  that  may  yield  imprecise  results. 

While  advances  in  priority  scheduling  have  been  promising,  several  factors  limit  its  use  in 
supervisory  real-time  systems.  The  static  scheduling  techniques  require  a  significant 
amount  of  a  prion  knowledge  about  task  arrival  rates  and  times.  It  is  often  not  possible  to 
know  this  information  in  dynamic  environments.  The  approach  also  does  not  distinguish  be¬ 
tween  the  timeliness  requirements  and  the  importance  of  individual  tasks.  An  activity  is  not 
necessarily  urgent  just  because  it  is  very  important.  Nor,  is  it  very  important  merely  be¬ 
cause  it  is  urgent.  Because  both  the  urgency  and  importance  must  be  statically  encoded  into 
a  single  value,  priority -based  schemes  are,  in  general,  unable  to  support  the  kind  of  dynamic 
normal-case  scheduling  and  overload  handing  that  is  needed  in  the  supervisory  real-time  do¬ 
main. 

The  second  major  area  of  real-time  scheduling  research  has  investigated  methods  of  us¬ 
ing  explicit  deadlines  to  schedule  real-time  activities.  In  most  cases  this  work  has  only  con¬ 
sidered  hard  deadlines.  The  earliest  deadline  (ED)  algorithm  has  been  shown  to  be  optimal 
for  uniprocessors  by  [Dertouzos  74],  Unfortunately,  the  basic  ED  scheduling  algorithm  is 
unstable  under  overload  conditions  [Conway  67].  Several  researchers  have  considered 
methods  of  improving  the  overload  behavior  of  deadline  scheduling.  At  the  University  of 
Massachusetts,  [Ramamritham  84]  has  developed  dynamic  scheduling  techniques  which  will 
only  accept  a  task  for  execution  if  it  can  be  guaranteed  to  meet  its  deadline.  However,  the 
consequence  of  this  guarantee  is  that  extremely  important  activities  may  be  blocked  by  less- 
important  activities  that  have  already  been  scheduled.  To  handle  this  problem,  the  seman¬ 
tics  of  the  guarantee  have  been  relaxed  in  (Biyabani  88a]  and  [Biyabani  88b]  to  permit  high¬ 
er-priority  tasks  to  revoke  guarantees  made  to  lower-priority  ones. 

Locke  developed  a  scheduling  algorithm  known  as  the  best-effort  (LBE)  algorithm  [Locke 
86]  which  handles  overloads  in  a  manner  more  consistent  with  the  goals  of  supervisory  real¬ 
time  systems  [Jensen  85].  A  Mach  implementation  and  complexity  evaluation  of  Locke’s 
original  algorithm  is  described  in  [Wendorf  88],  .An  improved  best-effort  algorithm,  imple¬ 
mented  for  the  Alpha  operating  system  [Northcutt  88b],  has  been  evaluated  in  [Trull  88],  In 
related  work,  Clark  has  developed  an  approach  to  scheduling  dependent  real-tune  activities 
with  similar  goals  [Clark  88].  Although  previous  work  in  this  area  has  been  very  successful, 
limitations  still  exist.  In  particular,  previous  work  has  not  adequately  considered  how  physi¬ 
cal  distribution  or  nested  timeliness  requirements  affect  the  scheduling  problem. 
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Little  research  has  been  conducted  to  investigate  the  effects  of  physical  distribution  on 
the  scheduling  of  composite  real-time  activities.  Most  distributed  scheduling  papers  de¬ 
scribe  load-sharing  techniques,  but  never  consider  the  possibility  that  a  time-constrained  ac¬ 
tivity  may  span  multiple  nodes.  Examples  of  results  which  fall  into  this  category  are 

(Ramamntham  84],  [Stankovic  84],  [Stankovic  85],  [Zhao  85],  [Kurose  86],  and  [Kurose 
87],  The  most  closely  related  research  addresses  the  scheduling  of  groups  of  precedence-re¬ 
lated  tasks  with  hard  deadlines  [Cheng  86].  Cheng  describes  methods  of  synthesizing  inter¬ 
mediate  time  constraints  known  as  pseudo  windows  to  ensure  that  tasks  in  a  group  are 

scheduled  to  satisfy  the  group's  deadline.1  In  general,  the  pseudo  window  technique  re¬ 

quires  that  complete  knowledge  about  the  execution  characteristics  of  all  group  members  be 
available  when  the  first  member  of  the  group  arrives.  Although  such  extensive  knowledge 
does  allow  more  intelligent  scheduling  decisions  to  be  made,  the  system  dynamics  often  limit 
the  extent  to  which  this  information  is  available. 

Related  scheduling  work  in  the  field  of  operations  research  has  addressed  the  problem  of 
multistage  production  planning  [Johnson  74],  Unfortunately,  techniques  such  as  linear  pro¬ 
gramming  [Winston  87]  which  are  often  employed  in  these  situations  are  not  practical  for  on¬ 
line  scheduling. 

1.3  Technical  Approach 

As  the  previous  section  indicates,  existing  research  has  addressed  only  parts  of  the  su¬ 
pervisory  real-time  scheduling  problem.  This  work  will  extend  the  range  of  that  coverage  to 
include  the  scheduling  of  composite  real-time  activities — that  is.  time-constrained  activities 
that  may  span  multiple  processing  nodes  and  may  have  multiple  nested  timeliness  require¬ 
ments. 

This  research  will  be  divided  into  three  major  stages: 

•  creation  of  a  computational  model  for  composite  real-time  activities, 

•  development  of  time-driven  scheduling  techniques  for  composite  activities,  and 

•  analysis  and  evaluation  of  the  proposed  techniques. 

The  following  sections  describe  in  greater  detail  the  work  involved  and  results  to  date  in 
each  of  these  areas 


l 


This  use  of  pseudo  windows  should  not  be  confused  with  the  case  where  nested  ume  constraints  are  actually 
imposed  by  the  application. 


B-6 


Time-Driven  Scheduling  of  Composite  Real-Time  Activities 


2.  Computational  Model 

The  first  stage  of  the  research  involves  the  development  of  a  new  computational  model 
which  can  be  used  to  describe  the  behavior  and  timeliness  requirements  of  composite  real¬ 
time  activities.  The  model  must  account  for  the  physical  distribution  of  time-constrained  ac¬ 
tivities  and  must  specify  meaningful  methods  for  composing  multiple  nested  timeliness  re¬ 
quirements. 

2.1  Modeling  Timeliness  Requirements 

This  work  uses  the  notion  of  time-value  functions  [Jensen  75]  to  specify  the  timeliness 
requirements  of  activities.  Time-value  functions  express  the  time-varying  value  to  the  appli¬ 
cation  of  completing  an  activity.  Some  example  specifications  are  shown  in  Figure  1..  Using 
this  model,  a  hard  deadline  (Figure  la)  is  specified  by  a  step  function  where  the  completion 
value  is  a  constant  positive  number  between  the  request  time  (tr)  and  the  deadline  (tqp,  and 
is  zero  after  the  deadline.  The  glue/join  activity  descnbed  in  the  toy  factory  example  would 
have  a  time  value  function  similar  to  Figure  lb,  where  the  utility  of  finishing  the  work  increas- 


(a)  (b) 


Figure  1:  Example  Time-Value  Functions 
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Figure  2:  Time-Value  Function  Specification 


es  (as  the  glue  becomes  tacky)  until  a  critical  time  ( tcj ),  is  constant  for  an  interval  (until  tc2, 
when  the  glue  begins  to  dry),  and  gradually  decreases  to  zero  afterward  (when  the  partially 
assembled  truck  must  be  discarded  at  ta ,  the  abort  time). 

In  theory',  time-value  functions  may  have  arbitrary  shapes.  To  simplify  their  specification 
in  real  systems  such  as  [Locke  86],  [Tokuda  87],  and  [Northcutt  88b],  time-value  functions 
are  often  modeled  by  a  set  of  continuous  functions  and  reference  tunes.  In  this  w'ork,  time- 
value  functions  will  be  specified  by  three  reference  times  (fr,  tc).  and  rc2 ),  and  three  continu¬ 
ous  functions  ( Vearly ,  Vmid,  and  Viatel  (see  Figure  2).  In  the  most  general  case,  each  of  the 
functions  has  the  form: 

V(t)  =  Kj  +  K2t+K3r  +  K4e'K5‘ 

In  most  cases,  however,  this  research  will  consider  only  linear  functions  (/.*’.,  Ks-K4=0). 

This  restriction  still  allows  most  interesting  time-value  functions  to  be  approximated,  yet 
greatly  simplifies  the  mathematics  which  must  be  handled  by  the  scheduler.  The  abort  time 
( ta ),  the  time  after  which  the  activity  is  aborted  and  any  exception  processing  is  initiated,  is 
defined  as  the  earliest  time  when  Vlate  =  0. 

When  timeliness  requirements  are  nested,  appropriate  techniques  of  composing  the  time- 
value  functions  must  be  developed.  It  is  not  sufficient  to  consider  only  the  innermost  require¬ 
ment  since  that  constraint  may,  in  fact,  not  be  the  most  stringent.  Nor  may  it  be  appropriate 
to  use  only  the  most  stringent  constraint  when  deciding  on  the  ultimate  value  of  an  activity 
In  the  toy  truck  example,  there  may  be  no  inherent  value  in  successfully  gluing  the  chassis 
and  body  together  if  the  wheels  are  never  attached.  At  present,  work  is  continuing  on  efforts 
to  identify  appropriate  methods  of  composing  nested  time  constraints. 
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2.2  Modeling  Composite  Activities 

Previous  time-driven  scheduling  research  has  only  considered  activities  that  remain  lo¬ 
cally  executable  from  the  time  they  arrive  until  they  complete.  Under  these  conditions,  the 
execution  characteristics  of  an  activity  can  be  modeled  by  a  single  statistic,  the  estimated 
computation  time  (ECT).  As  explained  in  the  truck  assembly  problem,  composite  real-time 
activities  may  involve  computation  on  several  processing  nodes.  Because  of  this  distribu¬ 
tion,  the  total  computation  time  will  also  be  divided  among  multiple  nodes.  To  completely  de¬ 
scribe  the  execution  characteristics  of  a  distributed  activity,  the  computation  tune  on  each 
node  must  be  specified. 

One  useful  way  of  modeling  the  distributed  activities  is  to  view  them  as  having  multiple 
stages — each  of  which  may  execute  on  a  different  processing  node.  An  activity  can  then  be 
descnbed  as  a  linear-connected  graph  of  execution  stages.  Tune  constraint  specifications 
can  be  modeled  by  adding  graph  elements  corresponding  to  the  beginning  and  end  of  each 
time  constraint.  Figure  3  illustrates  how  the  toy  truck  assembly  activity  is  modeled  using 
this  technique.  For  each  execution  stage,  the  estimated  computation  time,  ECTin ),  of  that 
stage  is  specified. 


Key 


Execution  on  Node  1 

ECT(m) 

Benin  Tune  Constraint 

S'/ 

I  u 

Execution  on  Node  2 

§ECTtn,  | 

End  Time  Constraint 

/ 

Figure  3:  Graph  Mode!  of  Toy  Truck  Assembly 
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Although  the  full  generality  of  the  graph-based  model  is  not  strictly  needed  to  handle  dis¬ 
tributed  activities,  the  model  is  useful  since  it  can  be  easily  extended  to  include  general  re¬ 
source  requirements  and  the  concurrent  execution  of  component  stages  of  an  activity. 
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3.  Scheduling  Techniques 

Once  the  computational  model  has  been  finalized,  new  time-driven  scheduling  techniques 
will  be  developed.  These  techniques  will  use  limited  information  about  the  timeliness  re¬ 
quirements  and  execution  characteristics  of  composite  real-time  activities  to  ensure  that  as 
much  useful  work  as  possible  is  completed  by  the  application.  Under  normal  (i.e.,  non-over- 
load)  conditions,  the  algorithms  will  attempt  to  satisfy  all  of  the  system  timeiiness  require¬ 
ments.  When  overloads  occur,  the  algorithms  will  be  designed  tp  shed  load  intelligently  so 
that  activities  which  are  scheduled  will  meet  their  time  constraints  and  will  contribute  as 
much  value  as  possible  to  the  system 

The  scheduling  problem  can  be  divided  into  three  major  components: 

•  ordering  of  activities, 

•  overload  detection,  and 

•  load  shedding. 

Several  techniques  have  been  suggested  for  ordering  time-constrained  activities.  Both 
ED  and  least  slack  ( LSi  ordering  are  known  to  be  optimal  for  uniprocessors  [Nlok  83],  Unfor¬ 
tunately,  neither  approach  is  optimal  in  the  multiprocessor  case.  Simulation  results  [Locke 
86]  have  shown,  however,  that  ED  scheduling  still  performs  well  on  multiprocessors.  [Stone 
77]  suggests  that  network  flow  algorithms  can  be  used  effectively  for  processor  scheduling. 
Still  another  approach  handles  task  ordering  as  a  planning  problem  where  search  techniques 
are  used  to  find  an  acceptable  execution  order  [Ramamritham  84],  The-.e  search  techniques 
are  imperfect,  but  tractable.  Several  task  ordering  alternatives  will  be  considered  for  possi¬ 
ble  inclusion  in  the  new  scheduling  algorithms.  The  most  likely  candidates  Include  ED  order¬ 
ing,  and  an  explicit  placement  algorithm  which  allows  varying  levels  of  "greediness"  to  be 
applied. 

Overload  detection  relies  on  the  use  of  execution  time  estimates  to  determine  whether 
there  are  enough  processor  cycles  to  schedule  ail  contending  activities  within  their  time  con¬ 
straints.  In  many  dynamic  real-time  systems,  this  calculation  is  performed  during  the  task 
ordering  process  by  calculating  the  cumulative  slack  time  for  the  processor.  If  the  cumulative 
slack  for  any  time  interval  drops  below  zero,  the  processor  is  overloaded.  The  problem  of 
overload  detection  is  complicated  by  distnbuted  computations.  If  the  distribution  is  not  con¬ 
sidered,  the  local  demand  for  the  processor  will  be  overestimated.  This  exaggeration  could 
cause  "false"  overload  indications  to  be  generated,  potentially  preventing  activities  from 
meeting  their  time  constraints  (due  to  load  shedding). 
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The  problem  of  false  overloads  can  be  ameliorated  by  incorporating  additional  knowledge 
into  the  overload  detection  process.  The  alternative  which  uses  the  least  additional  execu¬ 
tion  information  is  one  in  which  estimates  for  both  local  computation  time  ( LCT >  and  total 
computation  time  (TCT)  are  specified  as  pan  of  a  time  constraint.  In  the  general  case,  the 
activity  must  specify  LCT's  for  each  of  the  nodes  it  may  visit.  The  local  scheduler  would  con¬ 
tinue  to  use  the  TCT  figure  to  determine  the  ordering  of  the  schedule,  but  would  use  the  LCT 
figure  when  performing  slack  time  calculations  for  the  processor.  The  use  of  LCT  and  TCT 
estimates  should  reduce  the  number  of  false  overload  signals.  However,  false  indications 
may  still  occur  since  LCT/TCT  estimates  do  not  specify  when  in  an  activity’s  execution  the 
processor  time  will  be  needed.  If  most  of  the  required  time  comes  late  in  the  activity,  then 
more  near-term  (and  fewer  far-term)  processor  cycles  may  be  available  than  the  LCT/TCT 
ratio  would  indicate.  More  accurate  overload  detection  could  be  achieved  if  ECT’s  were 
available  for  each  stage  of  an  activity’s  execution.  However,  additional  processing  would  be 
required  to  process  the  additional  information.  It  might  also  be  impractical  or  impossible  to 
gather  such  detailed  execution  profiles. 

Load  shedding  in  time-driven  systems  relies  on  the  notion  of  value  density  [Locke  86]  to 
determine  which  activities  are  likely  to  contribute  the  most  to  the  application.  Value  density 
measures  how  much  value  per  unit  of  processing  time  will  be  returned  to  the  application  for 
executing  a  particular  activity.  When  a  limited  number  of  processor  cycles  are  available,  exe¬ 
cuting  the  activities  with  the  highest  value  density  is  likely  to  result  in  the  most  useful  w'ork 
being  accomplished.  In  a  distributed  environment,  load  shedding  decisions  are  more  difficult 
since  an  activity  with  a  relatively  low  value  density  might  only  require  a  few  cycles  locally 
before  travelling  to  a  more  lightly-loaded  node  where  its  time  constraints  could  be  satisfied. 
The  load  shedding  algorithms  should  be  able  to  utilize  the  same  types  of  extended  execution 
information  (LCT,  TCT)  as  the  overload  detection  algorithms,  although  a  better  solutions 
would  like  require  cooperation  between  schedulers  at  different  nodes. 

The  existence  of  nested  timeliness  requirements  complicates  load  shedding  by  making  it 
more  difficult  to  determine  the  value  density.  Since  the  value  of  satisfying  a  time  constraint 
may  depend  both  on  the  innermost  constraint  and  on  outer-level  constraints,  a  composition 
function  must  be  applied  to  determine  the  true  potential  value  for  the  activity.  Work  is  in 
progress  which  will  specify  methods  of  composing  time-value  functions. 

Research  into  the  specific  scheduling  algorithms  is  still  in  its  initial  stages.  Many  of  the 
tough  decisions  will  be  easier  to  make  once  the  computational  model  has  been  finalized  and 
techniques  for  composing  nested  time-value  functions  have  been  developed. 
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4.  Evaluation  Methodology 

The  evaluation  of  the  proposed  scheduling  techniques  will  judge  how  well  they  satisfy  the 
requirements  of  the  supervisory  real-time  environment.  Simulation  experiments  will  be  used 
to  evaluate  the  performance  of  the  new  algorithms  compared  to  existing  methods  such  as 
earliest  deadline  and  Locke’s  best-effort  approach. 

Because  the  execution  of  time-driven  scheduling  algorithms  can  be  costly  compared  to 
other  algorithms,  scheduling  overhead  will  be  explicitly  considered  in  the  simulation  experi¬ 
ments.  There  are  two  primary  techniques  for  estimating  scheduling  overhead:  1)  mathemati¬ 
cally  deriving  the  theoretical  complexity  of  the  scheduling  algorithm  and  2)  measuring  the  ac¬ 
tual  performance  of  a  sample  implementation.  Both  techniques  yield  useful  results  and  will 
be  employed  in  this  research.  The  complexity  analysis  provides  worst-case  information  de¬ 
scribing  how  the  overhead  changes  with  increasing  load.  Simple  O(n)  analysis,  however, 
does  not  reveal  the  magnitude  of  the  constant  and  scale  factors.  Actually  measuring  the  per¬ 
formance  of  a  sample  implementation  provides  valuable  information  about  these  scale  factors 
(compared  with  other  algorithms)  and  reveals  how  the  algorithm  behaves  on  common  (i.e., 
non-worst-case)  workloads. 

Evaluating  the  proposed  techniques  using  only  one  or  two  “real”  workloads  would  likely 
skew  the  results  to  reflect  the  peculiarities  of  the  chosen  systems.  For  this  reason,  a  wide 
range  of  synthetic  workloads  will  be  used  to  test  the  performance  of  the  algorithms.  Sensi¬ 
tivity  analysis  will  be  used  to  measure  how  their  behavior  changes  as  different  components 
of  the  workload  are  varied. 

4.1  Evaluation  Metrics 

Many  metrics  have  been  devised  for  evaluating  the  performance  of  real-time  scheduling 
algorithms.  For  time-driven  systems,  the  most  important  measure  of  an  algorithm’s  perfor¬ 
mance  is  how  much  of  an  application's  potential  value  is  obtained  using  the  algorithm.  Since 
the  fraction  of  the  maximum  completion  value  obtained  for  each  activity  directly  corresponds 
to  how  well  its  time  constraints  have  been  satisfied,  the  value  metric  indicates  both  how  well 
the  system  time  constraints  have  been  satisfied,  and  to  what  degree  the  scheduler  has  suc¬ 
ceeded  in  scheduling  the  most  useful  activities  under  overload  conditions.  Because  optimal 
scheduling  is  intractable  in  the  systems  of  interest,  it  is  not  practical  to  compute  the  maxi¬ 
mum  value  that  could  actually  be  garnered  by  a  perfect  scheduling  algorithm.  Instead,  a  sim¬ 
ple  upper  bound  on  the  potential  value  can  be  generated  by  summing  the  maxima  of  the  val- 
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ues  for  the  activities  in  a  workload.  This  total  potential  value  ( TPV )  is  then  compared  to  the 
actual  value  obtained  ( AVO >  to  yield  the  percentage  of  value  obtained  (PYO  i  by  the  algorithm. 

Several  other  metrics  have  been  designed  to  measure  how  well  an  algorithm  satisfies  the 
goals  of  lower-level  systems  and  are  not  directly  applicable  to  the  supervisory  real-time  en¬ 
vironment.  However,  some  of  thes~  low-level  metrics  can  be  adjusted  to  provide  useful  in¬ 
formation  about  algorithm  behavior  for  certain  workloads. 

In  systems  where  all  tasks  are  presumed  to  have  deadlines  and  are  not  distinguished  by 
value,  the  performance  of  scheduling  algorithms  is  often  judged  by  monitoring  the  percentage 
of  tasks  which  complete  after  their  deadlines  (i.e.,  are  tardy).  In  these  cases,  the  mean  tardi¬ 
ness  and/or  the  maximum  tardiness  of  the  late  tasks  are  often  considered  as  well.  For  time- 
driven  systems,  the  percentage  of  tardy  activities  (PTA)  is  only  relevant  if  it  is  theoretically 
possible  to  schedule  the  workload  being  considered  so  that  it  obtains  its  total  potential  val¬ 
ue.  Under  these  conditions,  the  PTA  metric  can  provide  useful  information  about  the  behav¬ 
ior  of  the  algorithm.  Statistics  on  mean  tardiness  and  maximum  tardiness  do  not  consider 
the  relative  importance  of  the  late  activities  and,  therefore,  are  not  relevant. 

Other  metrics  which  may  provide  useful  information  for  evaluating  the  behavior  of  the  pro¬ 
posed  algorithms  include: 

•  average  scheduling  overhead — the  average  time  required  to  choose  the  next  activity  to 
run,  and 

•  number  of  preemptions — the  total  number  of  preemptions  generated  (useful  for  estimat¬ 
ing  context  sw'ap  overhead). 

4.2  Workload  Generation 

A  synthetic  workload  generator  will  be  used  to  construct  test  cases  for  the  simulation  ex¬ 
periments.  By  using  synthetic  workloads,  a  wide  range  of  application  environments  can  be 
simulated.  [Woodbury  86]  has  investigated  methods  of  developing  workloads  for  distribut¬ 
ed  real-time  systems.  Although  the  computational  model  considered  by  Woodbury  is  more 
constrained  than  the  once  presented  in  Section  2,  the  work  does  explore  the  issues  which 
lead  to  stochastic  behavior  of  distributed  activities.  Other  work  such  as  [Maynard  88]  will 
be  used  to  identify’  important  characteristics  of  supervisory'  real-time  applications  which 
should  be  modeled  in  the  workloads. 

Simulation  experiments  will  be  conducted  while  varying  such  factors  as: 

•  mean  number  of  activities, 

•  mean  activity  arrival  rates, 
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•  mean  and  standard  deviation  of  activity  execution  times, 

•  percentage  of  local  versus  remote  execution  times,  and 

•  level  of  system  “dynamics"  (i.e.,  how  the  characteristics  of  the  workload  change 
across  time). 

Sensitivity  analysis  will  be  used  to  determine  which  workload  variations  have  the  great¬ 
est  impact  on  the  behavior  of  the  various  algorithms.  Using  these  results,  it  should  be  possi¬ 
ble  to  characterize  the  types  of  workloads  which  are  best  handled  by  the  proposed  tech¬ 
niques.  These  results  will  also  be  used  to  suggest  techniques  for  tailoring  the  proposed  al¬ 
gorithms  to  more  closely  match  certain  environments. 
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5.  Research  Schedule 

•  8/30/89  —  Thesis  proposal. 

•  10/31/89  —  A  computational  model  will  have  been  developed  and  shown  to  be  suitable 
for  modeling  composite  real-time  activities  and  their  timeliness  requirements.  Tech¬ 
niques  for  using  the  information  available  from  the  expanded  model  will  have  been  pro¬ 
posed. 

The  specification  of  the  composite  activity  execution  model  is  largely  complete.  More 
work  is  needed  to  formalize  techniques  for  composing  nested  time  constraints  and  to 
identify  what  types  of  processor  utilization  information  can  be  made  available  to  the 
scheduler  at  run  time. 

•  12/31/89  —  Specific  scheduling  algorithms  will  have  been  developed.  A  complexity 
analysis  of  the  proposed  algorithms  will  have  also  been  completed. 

Initial  investigations  have  been  made  to  identify  possible  scheduling  techniques.  Al¬ 
though  tentative,  this  work  indicates  that  promising  techniques  do  exist. 

•  2/28/90  —  A  simulator  and  synthetic  workload  generator  will  have  been  designed  and 
implemented. 

•  5/31/90  —  Simulation  experiments  will  have  been  completed.  The  proposed  scheduling 
algorithms  will  have  been  evaluated  and  refined  to  the  point  where  final  analyses  can 
be  performed. 

•  8/31/90  —  Data  from  the  simulation  work  will  have  been  analyzed  and  a  thesis  describ¬ 
ing  the  results  of  the  research  will  have  been  completed. 
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6.  Research  Contribution 

The  contributions  of  this  research  can  be  classified  into  three  major  categories — the  cre¬ 
ation  of  a  computational  model  for  composite  real-time  activities,  the  development  of  sched¬ 
uling  techniques  suitable  for  the  supervisory  real-time  environment,  and  the  analysis  and 
evaluation  of  scheduling  techniques  that  are  suitable  for  different  types  of  supervisory  sys¬ 
tems. 

A  new  computational  model  will  be  developed  for  describing  composite  real-time  activi¬ 
ties.  This  model  will  account  for  the  physical  distribution  of  time-constrained  activities  and 
will  specify  suitable  methods  for  composing  multiple  nested  timeliness  requirements.  No  ex¬ 
isting  models  can  adequately  describe  the  behavior  and  requirements  of  such  activities.  The 
computational  model  will  be  designed  so  that  it  can  be  easily  extended  to  consider  both  gen¬ 
eral  resource  requirements  and  the  concurrent  execution  of  component  stages. 

New  time-driven  scheduling  techniques  will  be  developed.  These  techniques  will  rely  on 
limited  information  about  the  timeliness  requirements  and  execution  characteristics  of  com¬ 
posite  real-time  activities  to  schedule  activities  so  that  as  much  useful  work  as  possible  is 
completed  by  the  application.  Under  normal  (i.e.,  non-overload)  conditions,  the  algorithms 
will  attempt  to  satisfy  all  of  the  system  timeliness  requirements.  When  overloads  occur,  the 
algorithms  will  be  designed  to  shed  load  intelligently  so  that  activities  which  are  scheduled 
will  meet  their  time  constraints  and  will  contribute  as  much  value  as  possible  to  the  system. 

Finally,  the  proposed  scheduling  methods  will  be  analyzed  under  a  wide  range  of  loading 
conditions.  The  performance  of  the  new  algorithms  will  be  compared  to  that  obtained  using 
existing  approaches.  The  results  of  this  analysis  will  be  used  to  delineate  the  domain  in 
which  the  new  techniques  are  applicable  and  to  suggest  methods  for  tailoring  the  algorithms 
to  specific  types  of  real-time  environments. 
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Chapter  1 
Introduction 


This  is  a  draft  of  a  doctoral  dissertation.  The  work  presented  is 
continuing.  The  material  contained  in  this  draft  will  be  edited,  and 
possibly  augmented,  to  produce  the  final  version  of  the  dissertation. 

Real-time  applications  are  typically  composed  of  a  number  of  cooperating  activities,  each  contributing 
toward  the  overall  goals  of  the  application.  The  physical  system  being  controlled  dictates  that  these 
activities  must  execute  certain  computations  within  specific  time  intervals.  For  instance,  safe  operating 
practices  may  dictate  that  an  activity  scheduled  in  response  to  an  alarm  condition  must  complete  execution 
within  several  milliseconds  of  the  receipt  of  the  alarm  signal. 

Real-time  applications  usually  contain  more  activities  that  must  be  executed  than  there  are  processors  on 
which  to  execute  them.  Consequently,  several  activities  must  share  a  single  processor,  and  the  quesuon  of 
how  to  schedule  the  acnviues  for  any  specific  processor  —  that  is.  deciding  which  activity  should  be  run 
next  on  the  processor  —  must  be  answered.  Necessarily,  the  prime  concern  in  making  scheduling 
decisions  in  real-time  systems  is  satisfying  the  timing  constraints  placed  on  each  individual  activity, 
thereby  satisfying  the  timing  constraints  placed  on  the  entire  application. 

One  factor  significantly  complicates  the  scheduling  problem:  the  activities  to  be  scheduled  are  not 
independent.  Rather,  the  activities  share  data;  execute  mutually  exclusive  pieces  of  code,  called  critical 
sections  [Peterson  85];  and  send  signals  to  one  another.  All  of  these  interactions  can  be  modeled  as 
contention  for  resources  that  may  not  be  shared.  That  is,  once  an  activity  has  gained  access  to  a  shared 
resource,  then  no  other  activity  can  gain  access  to  it  until  the  first  activity  has  released  it.  Any  activity  that 
is  waiting  for  access  to  a  resource  currently  held  by  another  activity  is  said  to  depend  on  that  activity,  and  a 
dependency  relationship  is  said  to  exist  between  them.  Dependency  relationships  are  able  to  encompass 
both  precedence  constraints,  which  express  acceptable  execution  orderings  of  activities,  and  resource 
conflicts,  which  result  from  multiple  concurrent  requests  for  shared  resources. 

No  existing  scheduling  algorithm  solves  the  problem  of  scheduling  a  number  of  activiues  with  dynamic 
dependency  relationships  in  a  way  that  is  suitable  for  real-time  systems.  This  thesis  addresses  that 
problem.  The  resulting  work  provides  an  effective  scheduling  algorithm,  a  formal  model  to  facilitate  the 
analytic  proof  of  properties  of  that  algorithm,  and  simulation  results  that  demonstrate  the  utility  of  the 
algorithm  for  real-ume  applicanons. 
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1.1.  Problem  Definition 

A  real-time  system  consists  of  a  set  of  cooperating,  sequential  activities.  These  activities  may  be  Mach 
threads  [Mach  86],  Alpha  threads  [Northcutt  87],  UNIX  processes  [Ritchie  74],  or  any  other  abstraction 
known  to  the  operating  system  that  embodies  action  in  a  computer. 

These  activities  interact  by  means  of  a  set  of  shared  resources.  Examples  of  resources  are:  data  objects, 
critical  code  sections,  and  signals.  Any  given  resource  may  be  used  by  only  one  activity  at  a  time.  If 
activity  A}  is  accessing  a  resource  when  activity  A,  requests  access  to  the  same  resource.  A,  must  be  denied 
access  until  At  has  released  the  resource.  Here,  activity  A,  depends  on  activity  At  since  it  cannot  resume 
its  execution  until  A;  has  released  the  resource. 

We  assume  that  activities  can  be  preempted  at  any  time.  That  is,  at  any  time,  the  activity  that  is  currently 
being  executed  by  the  processor  may  be  suspended.  Later,  it  may  either  be  resumed  or  aborted,  or  it  may 
never  be  executed  again.  If  the  activity  is  resumed,  it  will  continue  execution  at  the  point  at  which  it  was 
interrupted.  If  it  is  aborted,  the  resources  it  holds  will  be  returned  to  a  consistent  state  and  released. 

Of  course,  the  preemption  of  an  executing  activity,  which  is  a  manipulation  of  a  computing  abstraction, 
does  not  preempt  the  physical  process  that  the  activity  is  monitoring  and  controlling.  Regardless  of  the 
execution  state  of  the  corresponding  computer  activity,  the  physical  process  continues  to  exist  and. 
possibly,  to  change1. 

We  also  assume  that  scheduling  decisions  must  be  performed  on-line  —  that  is,  they  cannot  be 
determined  in  advance  due  to  the  dynamic  nature  of  the  systems  of  interest  For  instance,  while  the 
scheduler  knows  about  the  current  activities,  it  does  not  know  their  resource  requirements  (that  is,  which 
resources  will  be  needed,  for  how  long,  and  in  what  order)2.  Furthermore,  new  activities  may  be  created 
without  warning  —  perhaps  in  response  to  external  events.  Since  the  set  of  activities  to  be  scheduled  may 
change  over  time,  as  may  their  dependency  relationships,  the  scheduler  must  examine  the  activities  to  be 
scheduled  in  an  on-line  fashion. 

[Ullman  75]  demonstrated  that  the  general  preemptive  scheduling  problem  is  NP-complete,  implying  that 
tractable  scheduling  algorithms  in  even  fairly  simple  systems  cannot  be  optimal  in  all  cases.  Instead,  they 
are  designed  to  exhibit  properties  that  seem  likely  to  result  in  desirable  behavior.  As  will  be  shown,  our 
algonthm  possesses  a  number  of  promising  properties  with  respect  to  real-time  systems. 


'Furthermore,  ihe  concept  of  *n  aborted  compulation  is  somewhat  different  in  a  reaj  time  system  than  it  is  in  other  applications.  In 
Any  setting.  aborting  an  activity  should  result  in  returning  the  data  items  modified  by  that  activity  to  a  consistent  state.  However,  in  a 
real-ume  system  not  ail  of  the  actions  of  the  activity  are  nullified  by  restoring  consistent  data  values.  Changes  made  in  the  physical 
world  by  means  of  computer -control  led  actuators  may  have  to  be  nullified.  Opening  a  valve,  for  example,  may  have  had  an  effect  in 
the  physical  world  that  cannot  be  undone  by  simply  closing  the  valve  once  again.  In  such  cases,  further  compensatory  actions  may  be 
required. 

2For  specific,  restricted  applications,  it  may  be  possible  to  know  some  or  all  of  this  information  in  advance;  but.  in  general,  it  is 
impossible. 
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1.1.1.  Dependencies 

As  defined  earlier,  activity  Aj  depends  on  activity  >4,  if  activity  Aj  cannot  resume  execution  until  .4,  has 
taken  some  action.  For  example: 

1.  several  activities  access  a  shared  region  of  memory  and  access  is  arbitrated  by  a  lock,  when 
one  activity  holds  the  lock  when  another  activity  requests  it,  the  requesting  activity  is  blocked 
and  depends  on  the  first; 

2.  similarly,  locks  may  be  used  to  protect  devices  and  sections  of  code;  this  allows  the 
implementation  of  critical  sections,  for  instance,  in  this  case,  whenever  one  activity  is  blocked 
while  another  activity  is  executing  a  critical  section,  the  blocked  activity  depends  on  the 
executing  activity; 

3.  precedence  constraints,  which  impose  partial  orderings  on  the  execution  of  activities,  may  be 
implemented  by  means  of  signals  between  activities;  an  acuvity  that  must  complete  a 
computation  before  another  activity  can  begin,  for  instance,  signals  the  second  activity  when 
it  is  done;  the  signal  indicates  that  the  second  activity  can  resume  execution;  notice  that  the 
second  activity  depends  on  the  first  w  hile  it  is  blocked  waiting  on  the  arrival  of  the  signal. 

These  dependencies  clearly  have  an  effect  on  scheduling.  A  number  of  activities  may  be  blocked  due  to 
dependencies  on  other  activities,  but  their  resource  needs  are  real  and  should  be  taken  into  account  insofar 
as  possible  by  the  scheduler.  However,  in  a  typical  operating  system,  if  an  activity  is  blocked,  its 
requirements  are  not  considered  by  the  scheduler.  As  a  result,  important  activities  may  be  ignored  by  the 
scheduler.  In  particular,  in  a  real-time  system,  activities  that  have  pressing  time  constraints  may  be  ignored 
because  they  are  blocked  due  to  dependency  relationships. 

A  classic  example  of  this  type  of  behavior  exists  in  the  context  of  static  priority  scheduling 
systems  [Peterson  85].  The  most  important  activities  are  assigned  high  priorities,  while  less  important 
activities  are  assigned  low  pnonties3.  Suppose  that  a  low  priority  activity  is  executing  a  critical  section 
when  a  new  event  makes  a  medium  priority  activity  ready  to  run.  A  priority  scheduler  would  preempt  the 
low  priority  activity  immediately,  while  it  was  sull  executing  its  critical  code4.  If  a  high  priority  activity 
subsequently  became  ready  to  run,  it  would  preempt  the  medium  priority  activity.  Unfortunately,  if  the 
high  priority  activity  were  to  attempt  to  execute  a  critical  code  sectioa  it  would  be  blocked  and  the  medium 
pnontv  activity  would  resume  execution  regardless  of  the  relative  urgency  of  their  respective  time 
constraints. 

Another  example,  similar  to  the  one  just  presented,  will  be  examined  more  closely  in  a  later  section  of 
this  thesis. 

A  model  that  keeps  track  of  blocked  activities  and  the  reason  that  each  activity  w«  suspended  can  cover 
all  of  the  scenarios  that  have  been  mentioned  so  far.  Specifically,  acuvities  that  share  data  can  coordinate 


3Note  that  there  la  no  inherent  correlation  between  an  activity  !  priority  and  the  urgency  of  its  time  constraint.  This  u  a  key 
problem  with  static  priority  schedulers. 

4Some  systems  prevent  preemption  at  these  limes,  while  many  do  not  [KB  84.  Bach  86]  But  even  systems  that  prevent  preemption 
suffer  from  other  problems —  for  example,  they  have  longer,  potentially  unbounded,  response  times,  and  they  lose  information  by 
describing  an  activity  by  a  single  number,  its  priority.  This  latter  point  will  be  elaborated  in  later  sections  of  this  document. 
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access  to  that  data  by  means  of  a  lock  manager.  If  a  lock  request  is  granted,  then  the  data  may  be  accessed. 
If  a  lock  cannot  be  granted  immediately,  the  requesting  activity  is  blocked  and  becomes  dependent  on  the 
activity  currently  holding  the  lock. 

In  the  case  of  critical  sections,  permission  to  execute  a  critical  section  can  be  arbitrated  by  semaphores. 
When  an  activity  executes  a  P  operation  to  request  permission  to  execute  a  critical  section,  the  activity 
either  begins  executing  the  crincal  section  immediately,  or  it  is  blocked  because  another  activity  is  already 
executing  that  critical  section.  In  the  latter  case,  the  blocked  activity  is  dependent  on  the  completion  of  the 
activity  executing  its  cnucal  section.  Similar  dependencies  also  result  from  more  general  uses  of 
semaphores. 

Finally,  signals  between  activities  can  often  be  implemented  using  a  semaphore.  The  signal  onginator 
issues  a  V  operation,  enabling  the  signal  receiver  to  continue  execuuon  when  it  does  a  P  operation  to  detect 
whether  the  signal  has  been  sent  yet  If  the  V  precedes  the  /*,  then  the  signal  was  sent  before  the  receiver 
looked  for  it,  and  the  receiver  is  allowed  to  continue.  Otherwise,  the  s'gial  receiver  must  wait  until  the 
signaller  has  issued  the  signal.  At  that  time,  the  receiver  is  blocked  and  its  further  execution  depends  on  the 
continued  progress  of  the  activity  that  will  send  the  signal. 

In  each  case,  the  scheduler  can  acquire  the  information  it  needs  to  construct  a  complete  picture  of  the 
dependencies  in  the  system.  Conversely,  since  this  information  is  available,  this  thesis  applies  to  a  wide 
range  of  applications  and  systems  in  which  these  types  of  dependencies  occur. 

1.1.2.  Real-Time  Systems 

Despite  common  defiruuons  that  refer  to  artifacts  such  as  interruptability  in  the  kernel,  interrupt  latency, 
and  context  swap  times  [Rauch-Hindin  87],  real-time  systems  are  fundamentally  concerned  with  carrying 
out  acuvities  according  to  timing  constraints  imposed  by  an  application  —  that  is,  the  external  world.  The 
timing  constraints  imposed  by  the  external  world  imply  that  the  time  at  which  an  activity  is  performed  is 
just  as  important  as  the  correctness  of  the  computation  being  performed.  Note  that  a  faster  computer  that 
executes  activities  in  an  unfortunate  order  might  be  less  "real-time'’  than  a  slower  computer  that  executes 
the  acuvities  in  a  more  advantageous  order. 

There  are  several  classes  of  real-time  systems  [Bennett  88].  Low-level  real-time  systems  are  typified  by 
loop  control  applications,  where  computers  interrogate  sensors,  perform  a  fixed  set  of  calculations  on  the 
sampled  data,  along  with  other  state  information,  and  control  a  group  of  actuators  based  on  the  results  of 
tte  calculauons.  The  acuviues  that  implement  these  applications  are  often  executed  periodically  — 
sometimes  because  the  sensors  produce  data  periodically  (e  g.,  radar)  and  sometimes  because  the  control 
models  on  which  the  systems  are  based  require  periodicity. 

Often,  several  of  these  low-level  real-time  systems  are  monitored  and  controlled  by  a  higher  level 
real-time  system,  called  a  supervisory  control  system.  For  supervisory  control  systems,  the  application 
events  that  trigger  acuviry  are  typically  not  penodic;  rather,  they  occur  stochastically  —  for  example,  in 
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response  to  an  alarm  condition  or  to  indicate  the  completion  of  a  low-level  sequence  of  operations.  These 
events  represent  significant  changes  in  the  physical  world  and  must  be  handled  by  the  supervisory  control 
system  in  a  timely  manner.  So.  just  like  low-level  real-time  systems,  supervisory  control  systems  have 
physically  derived  time  constraints;  and,  in  fact,  meeting  these  nme  constraints  is  just  as  cntical  as  it  is  in 
low-level  systems. 

In  addition  to  monitoring  and  directing  the  low-level  real-time  systems,  supervisory  control  systems 
perform  strategic  planning  functions  —  that  is,  they  determine  how  to  coordinate  the  actions  of  the 
lower-level  systems  to  meet  the  application's  objectives  —  and  they  receive  direction  from  higher  level 
management  information  systems.  Typically,  this  information  would  include  the  specific  objectives  for  the 
supervisory  control  application  (for  example,  to  produce  the  goods  that  fill  a  given  set  of  orders  during  the 
current  shift).  Although  supervisory  control  activities  cooperate  to  provide  their  services,  they  still  contend 
for  access  to  shared  system  and  application  resources. 

Unfortunately,  the  policies  that  are  prevalent  in  non-real-time  systems  to  resolve  such  contention  are 
inappropriate,  and  may  in  fact  be  counterproductive,  in  real-time  systems  For  instance,  in  time-sharing 
systems,  fairness  is  desired  and  is  obtained  by,  among  other  things,  using  FIFO  queue  disciplines  and 
round-robin  schedulers  [Peterson  85],  This  approach  reflects  the  belief  that  all  activities  are  equallv 
significant.  However,  in  real-time  systems  this  is  clearly  not  the  case  —  some  activities,  and  hence,  some 
time  constraints,  are  decidedly  more  significant  than  others.  In  fact,  while  failing  to  satisfy'  some  time 
constraints  may  have  no  adverse  effect  on  the  physical  process  or  platform  being  controlled,  failing  to 
satisfy  others  can  have  catastrophic  effects.  A  few  examples  will  illustrate  the  varying  significance  that 
may  be  attached  to  meeting  specific  time  constraints. 

First  of  all,  consider  a  real-time  supervisory  control  system  in  a  process  control  setting  —  a  furnace  and  a 
continuous  caster  in  a  steel  mill.  Molten  steel  of  a  specific  chemistry  is  created  from  iron,  scrap,  and 
additional  materials  in  the  furnace.  When  the  metal  in  the  furnace  is  ready  to  be  converted  into  slabs  of 
solid  steel,  the  molten  metal  is  poured  into  a  large  ladle,  transported  to  the  caster,  poured  into  the  caster, 
and  cast  into  a  long,  continuous  slab  that  is  subsequently  cut  into  individual  slabs  of  appropriate  length. 
When  the  metal  is  originally  poured  into  the  caster's  "mold,"  it  is  liquid.  It  cools  in  the  "mold"  and  is  solid 
when  it  emerges,  ready  to  be  cut.  Several  low-level  real-time  systems  directly  control  the  furnace,  the 
caster,  and  several  related  pieces  of  equipment.  These  systems  are  monitored,  controlled  and  coordinated 
by  a  supervisory  control  system. 

In  this  setting,  there  are  several  types  of  supervisory  control  time  constraints  that  can  be  examined 
Roughly  speaking,  they  fall  into  three  classes:  (a)  tinm  constraints  that,  if  missed,  will  result  in  potential 
loss  of  life  and  property  (e.g.,  due  to  liquid  steel  spilling  over  the  area);  (b)  time  constraints  imposed  by  the 
physical  world  that  have  financial  penalties  if  they  are  missed  (e  g.,  losing  quality  control  statistics  for 
products,  resulting  in  potentially  unusable  products);  and  (c)  time  constraints  that  are  not  physically  based 
and  result  only  in  inconvenience  if  they  are  missed  (e.g.,  operator  display  requests). 


Military  systems  also  provide  examples  of  the  difference  in  importance  between  vanous  time  constraints. 
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For  a  fighter  plane,  for  instance,  the  most  importance  activities  are  those  that  serve  to  keep  the  plane  in  the 
air  and  the  pilot  alive;  the  activities  that  control  weapons  are  less  important,  although,  obviously,  they  are 
still  of  great  concern.  On  the  other  hand,  aboard  a  ship,  which  will  float  stably  without  constant  control,  the 
activities  in  charge  of  the  defensive  weapons  systems  may  well  be  more  important  than  those  that  steer  the 
ship. 

The  preceding  examples  demonstrate  that  there  are  a  number  of  time  constraints  that  an  application 
declares  and  that  there  are  significant  differences  in  kind  among  the  activities  expressing  those  time 
constraints.  It  makes  sense  to  talk  about  failing  to  satisfy  time  constraints  in  a  dynamic  system  because 
transient,  and  even  permanent,  increases  in  resource  demands  are  possible.  Some  difficult  questions,  then, 
involve  detecting  these  demand  peaks  and  deciding  which  time  constraints  should  be  satisfied  and  which 
should  not. 

One  final,  critical  observation  should  be  made.  Notice  in  the  examples  above  that,  although  each  activity 
was  operating  under  a  time  constraint,  there  was  a  classification  of  its  relative  importance  (compared  to 
other  activities)  that  was  independent  of  the  time  constraint.  That  is,  there  was  no  inherent  correlation 
between  the  activity’s  urgency,  which  was  captured  by  its  time  constraint,  and  its  importance.  A  critically 
important  activity  may  require  little  computation  time  and  may  have  a  very  loose  time  constraint  (relatively 
speaking).  In  that  case,  it  is  certainly  not  an  urgent  activity,  although  it  is  an  important  activity. 
Conversely,  a  relatively  unimportant  activity  may  have  a  time  constraint  that  is  very  tight.  Therefore,  it  is 
fairly  urgent  even  though  it  is  not  very  important  in  the  global  scneme  of  things.  Many  schedulers  are  able 
to  deal  with  an  activity’s  importance  (e.g.,  priority  schedulers  [Peterson  85])  or  its  urgency  (e.g.,  deadline 
schedulers  [Conway  67]),  but  few  attempt  to  distinguish  between  these  two  attributes  or  to  use  all  of  the 
information  that  is  captured  in  both  of  them. 

1.2.  Simple  and  Complex  Schedulers 

Two  distinct  approaches  may  be  taken  in  designing  and  constructing  a  scheduler.  On  one  hand,  a 
minimal  scheduler  can  be  provided  The  scheduling  may  be  list-driven,  like  the  rate  group  schedulers  used 
by  cyclic  executives  [GD  80,  Stadick  83,  MacLarcn  80];  or  it  may  employ  a  very  simple  algorithm,  like  a 
priority  scheduler.  Such  approaches  impose  a  low  system  overhead.  This  may  be  entirely  appropriate 
when  the  goal  is  to  maximize  system  throughput  or  to  support  a  simple  application  structure  so  that 
properties  (such  as  worst  case  load  behavior)  can  be  demonstrated,  but  it  is  not  obviously  the  best  approach 
for  systems  where  the  goal  is  to  satisfy  as  many  time  constraints  as  possible  or  obtain  the  highest 
application-specified  value  as  possible.  Furthermore,  minimal  schedulers  may  have  limited  applicability, 
as  evidenced  by  the  fact  that  they  are  already  stretched  to  the  limit  in  large,  dynamic  real-time  applications. 

Alternatively,  a  complex  scheduler  may  be  used.  In  this  case,  application  activities  tell  the  scheduler  their 
individual  needs  and  the  scheduler  attempts  to  satisfy  them,  making  decisions  based  on  global  information 
that  the  application  does  not  possess.  The  more  complete  and  accurate  the  information,  the  better  the  job 
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that  the  scheduler  can  do  in  managing  resources5;  and  processor  cycles,  of  course,  are  one  particularly 
important  resource. 

This  thesis  explores  the  latter  philosophy  by  allowing  the  scheduler  to  use  more  information  than  usual  in 
order  to  do  a  better  job  of  scheduling  for  real-time  systems.  There  are  two  major  points  that  must  be 
demonstrated  to  verify  the  quality  of  the  scheduling:  first  of  all.  the  individual  scheduling  decisions  must  be 
good  (i.e.,  show  that  the  "right"  activity  was  selected  for  execution);  and  secondly,  the  performance  penalty 
paid  for  employing  a  more  expensive  scheduling  algorithm  must  be  more  than  offset  by  improved 
scheduling  from  the  point  of  view  of  the  application  (i.e.,  show  that  the  scheduler  can  make  bener  use  of 
the  resources  required  to  make  the  scheduling  decisions  than  the  application  can).  Of  course,  not  every 
application  requires  a  complex  scheduler,  but  some  do,  and  this  thesis  explores  the  use  of  complex 
schedulers  to  support  those  applications. 

The  previous  discussion  has  focused  on  time  constraints  without  elaborating  on  the  precise  definition  of 
these  constraints.  The  term  has  deliberately  been  used  to  capture  the  general  notion  that  real-time 
computations  must  satisfy  certain  timing  requirements.  We  now  introduce  a  formal  method  to  describe 
time  constraints  and  introduce  some  additional  terminology.  Each  activity  in  a  real-time  application  is 
composed  of  a  sequence  of  disjoint  computational  phases ,  also  known  simply  as  phases.  The  application 
as  a  whole  makes  progress  when  its  component  activities  make  progress;  and  each  activity  makes  progress 
by  completing  its  computational  phases.  Therefore,  the  completion  of  a  computational  phase  marks 
measurable  progress  for  the  application,  and  this  progress  is  expressed  in  terms  of  value  units.  Associated 
with  each  phase,  then,  is  a  time-value  function  [Jensen  75]  that  specifies  that  phase's  time  constraint  —  it 
indicates  the  value  acquired  by  the  application  for  completing  the  phase  as  a  function  of  time. 

The  shape  of  the  time-value  function  is  arbitrary,  and  Figure  1-1  shows  a  few  examples.  Figure  1  - 1  (a) 
shows  a  step  function  of  height  v.  In  this  case,  completing  the  computational  phase  by  time  tdl  yields  value 
v,  while  completing  it  at  any  later  time  yields  no  value.  Figure  1-1  (b)  shows  a  situation  where  the  cutoff  in 
value  is  not  as  sharp.  Prior  to  time  tc,  the  value  associated  with  completing  the  computation  is  again  v. 
However,  following  that  time,  the  value  decreases  smoothly  until,  once  agaia  a  point  is  reached  after 
which  no  value  is  gained  by  completing  the  phase.  Finally,  Figure  1-1  (c)  corresponds  to  a  phase  that  must 
complete  within  a  certain  interval  in  order  to  acquire  a  non-zero  value  for  the  applicaboa  Although  sharp 
transitions  are  shown  at  both  tcI  and  tc2,  more  gradual  transitions  —  such  as  a  parabola  —  could  also  be 
used  Finally,  the  times  at  which  there  are  sharp  changes  in  time-value  functions  arc  known  as  critical 
times.  Times  tdl,  tc,  tcj,  and  tc2  are  all  critical  times. 

The  simple  step  function  shown  in  Figure  1  -  1(a)  illustrates  several  key  ideas  and  allows  the  introduction 
of  some  important  terminology.  First  of  all.  time  is  referred  to  as  a  deadline  since  it  represents  the  last 
instant  at  which  the  phase  can  complete  and  still  make  a  non-trivial  contribution  to  the  accrued  value  for 


’improved  scheduling  c«n  also  be  obtained  by  devoung  more  resources  to  analyzing  a  fixed  amount  of  scheduling  information. 
Although  the  main  thrust  of  this  thesis  is  to  study  the  use  of  more  information  than  usual,  the  algorithm  to  be  studied  also  requires 
significant  resources  for  the  scheduler.  The  resulting  implications  will  be  discussed  later  in  the  document. 
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Figure  1-1:  Examples  of  Time- Value  Functions 

the  application.  Value  v  is  called  the  importance  of  the  phase.  If  every  time-value  function  were  a 
step-function  and  all  of  the  step  functions  had  the  same  height  (importance),  then  each  phase  that  was 
completed  would  make  an  identical  contribution  to  the  progress  of  the  application  and  an  appropriate 
scheduling  strategy  would  complete  as  many  phases  as  possible  prior  to  their  respective  deadlines.  If, 
however,  different  phases  were  to  have  different  importances,  then  they  would  make  different  contributions 
to  the  value  accrued  by  the  application  and  the  scheduling  strategy  that  would  maximize  that  value  would 
be  different  Considered  over  the  lifetime  of  an  application,  a  greater  acaued  value  represents  a  more 
successful  appplication. 

If  resource  demands,  including  those  for  processor  cycles,  are  sufficiently  low,  then  all  activities  can  be 
scheduled,  thereby  accruing  a  large  value  for  the  application.  However,  in  the  event  that  it  is  impossible  to 
satisfy  all  of  the  activities’  resource  demands,  an  overload  exists.  In  this  case,  some  subset  of  the  activities 
will  meet  their  time  constraints,  while  others  will  not,  resulting  in  a  lower  accrued  value  for  the  applicauon. 
In  an  overload  situation,  the  scheduler  should  maximize  the  value  accrued  by  the  applicauon. 

With  an  understanding  of  the  simple  step  function  time-value  function  and  the  vocabulary  introduced 
above,  consider  again  the  notion  that  a  scheduler  can  do  a  more  effective  job  when  it  has  more  complete  or 
better  quality  information  on  which  to  base  decisions.  Consider  the  algorithms  a  scheduler  can  use  given 
specific  types  of  information  (unless  otherwise  noted,  these  are  all  discussed  in  (Conway  67],  [Janson 
85]  or  [Peterson  85]): 
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•  no  information  —  there  is  no  way  to  distinguish  activities  so  round-robin  or  random 
scheduling  of  ready  activities  would  be  appropriate; 

•  relative  importance  of  activities  —  priority  scheduling  of  ready  activities;  this  algorithm  would 
always  run  the  highest  priority  (most  important)  ready  activity; 

•  deadline  and  required  computation  time  of  activities  —  deadline  scheduling,  where  he  ready 
activity  with  the  nearest  deadline  is  always  selected  to  run.  or  slack-time  scheduling.  where  the 
ready  activity  that  has  the  least  slack-time6  is  always  selected  to  run,  would  be  optimal 
algorithms  with  this  information; 

•  time-value  functions  [Jensen  75],  which  capture  importance  and  nming  requirements  —  more 
complex  schemes  such  as  best-effort  scheduling  [Locke  86]  of  ready  activities  can  be 
employed;  Locke  showed  that  under  his  model,  this  approach  can  be  more  effective  than  those 
listed  above. 

This  thesis  will  explore  the  consequences  of  allowing  the  scheduler  to  have  access  to  not  only  the 
activities'  time-value  functions,  but  also  to  informanon  describing  the  dependency  relationships  existing 
between  activities.  This  should  enable  the  system  to  take  into  account  the  time  constraints  of  blocked 
activities,  allowing  a  better  ordering  of  activities,  along  with  the  earlier  detection  and  better  resolution  of 
overloads. 

Notice  that  the  dependency  information  that  is  to  be  used  by  the  proposed  scheduling  algorithm  is  not 
very  exotic  or  difficult  to  obtain  in  many  cases.  Often,  the  operating  system  or  a  system  utility,  such  as  a 
lock  manager,  holds  key  pieces  of  this  information.  Whenever  an  acnvity  is  unable  to  gain  immediate 
access  to  a  shared  resource,  it  is  typically  blocked.  At  that  point,  the  system  is  capable  of  noting  which 
resource  is  being  accessed,  as  well  as  the  identities  of  the  activities  holding  and  requesting  the  resource.  In 
other  cases,  straightforward  extensions  to  the  operating  system  interface  woul  1  provide  the  necessary 
dependency  information  for  the  scheduler's  use.  As  a  result,  if  the  algorithm  can  be  demonstrated  to  have 
sufficient  merit,  an  implementation  would  not  seem  to  be  unduly  difficult 

13.  Scheduling  Example 

In  order  to  demonstrate  some  of  the  points  that  have  been  made  earlier  and  to  illustrate  the  type  of 
problem  that  is  to  be  addressed  by  this  thesis,  consider  an  example. 

Assume  that  there  are  only  three  activities,  each  consisting  of  only  a  single  phase.  Designate  these  phases 
pa,  pb,  and  pc.  Phase  pa  has  a  relatively  low  importance,  requires  four  time  units  of  execution  time  to 
complete,  and  must  complete  execution  within  15  time  units  of  its  initiation  It  requires  the  use  of  shared 
resource  r.  It  requests  access  to  r  after  it  has  executed  for  one  time  uni;,  and  releases  r  afier  it  has  executed 

for  a  total  of  three  time  units 

Phase  pb  has  a  medium  importance,  requires  three  time  units  of  execution  time,  and  must  complete  within 
four  time  units  of  its  initiation.  It  also  uses  shared  resource  r.  Like  pa,  it  requests  r  after  it  has  executed  for 
one  time  unit  and  releases  it  after  it  has  executed  for  a  total  of  three  time  units. 


eslack-nme  =  deadline  -  preaent  lime  ■  required  computation  lime. 
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Phase  pc  has  a  relatively  high  importance,  requires  four  time  units  to  complete  execuoon,  and  must 
complete  within  ten  time  units  of  its  initiation.  It  does  not  access  shared  resource  r. 

All  of  these  phases  are  initiated  as  a  result  of  external  events.  Suppose  that  the  event  that  initiates  phase 
pa  occurs  at  time  t  =  0,  and  the  event  that  initiates  both  pb  and  pc  occurs  two  time  units  later.  This  implies 
that  the  deadline  for  completing  phase  pa  is  time  t  =  15,  the  deadline  for  completing  phase  pb  is  at  time  t  = 
6,  and  the  deadline  for  completing  phase  pc  is  time  r  =  12. 

If  these  phases  are  to  be  scheduled  using  a  priority  scheduler,  then  it  seems  clear  that  their  importance  to 
the  application  should  act  as  an  indication  of  the-r  priority.  Therefore,  if  Pri()  is  a  function  that  returns  the 
priority  of  a  phase  . . . 

PriiPa)  <  Pri(pb)  <  Pr'p) 

Also  notice  that  this  is  a  situation  where  urgency,  when  defined  as  the  nearness  of  a  deadline,  is  not  the 
same  as  importance.  To  see  this,  let  DL()  represent  a  function  that  returns  the  deadline  of  a  phase.  Then 

DL(pb)  <  DL(pc)  <  DL(pa) 

A  pnonty  scheduler  will  always  execute  the  ready  phase  with  the  highest  priority.  A  deadline  scheduler 
will  always  execute  the  ready  phase  with  the  nearest  deadline.  Whenever  a  phase  is  waiting  on  a  resource, 
it  is  blocked  and  so  is  not  ready.  Applying  these  rules  to  phases  pa.  pb,  and  pc  yields  the  execution  profiles 
shown  in  Figure  1-2.  The  x-axis  represents  time,  while  the  y-axis  indicates  which  phase  is  executing  at  any 
given  time.  Significant  events  in  the  executions  of  the  phases  are  indicated.  Notice  that  neither  the  pnonty 
scheduler  or  the  deadline  scheduler  could  meet  all  three  deadlines.  Both  failed  to  allow  phase  pb  to  meet  its 
deadline.  A  more  sophisticated  version  of  the  pnority  scheduler,  for  example  one  of  the  priority 
inheritance  schedulers  mentioned  earlier,  will  not  solve  the  problem  either.  The  algorithms  to  be 
investigated  in  this  thesis  will  solve  this  problem. 

1.4.  Motivation  for  the  Model 

Much  of  the  model  of  supervisory  control  systems  that  has  been  presented  is  straightforward  and  is 
largely  based  on  current  practices  and  systems.  Nonetheless,  a  few  points  —  most  notably  the  use  of 
application-specific  values  within  the  system  —  may  not  be  obvious  or  typical  of  existing  implementations. 
These  issues  will  be  further  explained  in  the  following  sections. 

1.4.1.  Accrued  Value 

Evaluating  a  scheduling  algorithm  by  determining  the  total  value  it  accrues  while  execuung  an 
application  is  unusual.  However,  not  only  is  it  intuitively  appealing,  it  is  also  appropriate  in  many  cases. 

The  intuitive  appeal  lies  in  the  view  that  accumulating  value  represents  making  progress.  As  each 
activity  completes  designated  portions  of  its  execution,  value  accrues  to  indicate  the  utility  to  the 
application  of  that  particular  computation. 
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Figure  1-2:  Execution  Profiles  for  Priority  and  Deadline  Schedulers 

While  this  might  sound  plausible  as  a  metric,  there  remains  the  question  of  whether  values  can  be 
assigned  meaningfully  to  computational  phases  of  an  activity.  In  many  instances,  there  is  strong  reason  to 
believe  that  this  is  the  case. 

The  class  of  process  control  applications  provides  one  example  of  the  applicability  of  uuc  approach. 
Typically,  one  or  more  processes  are  being  controlled  or  one  or  more  product'  are  being  manufactured 
under  the  supervision  of  a  single  supervisory  control  computer  system.  Since  the  goods  being  produced 
have  a  monetary  value,  it  is  possible  to  assign  values  to  particular  activities  based  on  the  commercial  worth 
of  the  goods  being  produced  by  each  activity.  Consequently,  the  use  of  a  scheduler  that  maximizes  the 
amount  of  value  accrued  for  the  application  is  actually  maximizing  the  commercial  value  of  the  goods 
being  produced.  This  seems  entirely  reasonable.  (Conversely,  if  it  seemed  more  natural,  the  notion  of 
monetary  loss  or  penalty  could  be  used  instead  of  the  monetary  value  or  profit  outlined  The  underlying 
notion  is  essentially  the  same  in  either  case.)7 

Dunng  an  overload,  when  there  are  insufficient  resources  to  meet  the  overall  demand,  some  activities 


7 The  use  of  monetary  measures  to  determine  schedule*  has  long  been  used  in  the  operations  research  and  job  shop  scheduling 
communiuc..  The  model  used  in  thus  work  differs  somewhat  from  their  model.  Dus  is  dealt  wall'  mi  some  depth  in  Chapter  6. 
Briefly,  the  typical  job  shop  model  assumes  that  the  set  of  orders  currently  known  will  all  be  filled  at  some  point  in  time.  That  is,  all 
activities  will  eventually  be  run.  This  docs  not  Lake  into  account  the  fact  that  m  real-time  computer  systems,  some  activities  are  of 
only  transient  value  because  they  are  run  frequently  or  because  they  must  be  run  in  a  timely  fashion  or  not  at  all  due  to  the  quality  of 
the  information  or  the  physical  time  constraints  of  the  application. 
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may  not  be  scheduled.  It  would  be  perfectly  reasonable  to  select  which  of  two  activities  snould  be  run 
based  on  their  relative  values.  In  fact,  it  would  be  possible  that  during  an  overload  involving  three  or  more 
activities,  the  activity  with  the  highest  individual  value  would  not  be  scheduled.  Rather,  two  or  more 
activities  with  lower  individual  values,  but  with  a  higher  combined  value,  could  be  scheduled. 

This  overload  behavior  should  be  contrasted  with  that  of  other  scheduling  policies.  For  instance,  a 
priority  scheduler  would  always  execute  the  activity  with  the  highest  individual  value  at  any  given  time 
(assuming  that  the  priorities  assigned  to  activities  corresponded  to  the  commercial  worth  of  the  activity  as 
described  previously).  In  the  case  just  outlined,  this  would  result  in  a  lower  total  value  than  th<*  method  that 
maximized  value. 

A  steel  mill  application  can  illustrate  this  point,  while  demonstrating  the  dynamic  nature  of  the 
assignment  of  values  to  tasks.  The  steel  mill  under  consideration  has  a  furnace  and  caster  that  combine  to 
transform  raw  materials  into  slabs  of  finished  steel  of  specified  chemistry.  There  are  two  functions  that  are 
particularly  interesting:  chemistry  control,  which  controls  the  chemical  composition  of  the  steel  being 
produced,  and  quality  control  tracking,  which  follows  the  progress  of  the  steel  through  various  stations  in 
the  mil!  including  the  caster  and  associates  a  specific  chemistry  with  each  foot  of  every  steel  slab  produced 
by  the  mill.  A  single  supervisory  control  computer  monitors  and  controls  both  of  these  functions. 

During  overloads,  the  supervisory  computer  may  have  to  decide  which  function  should  be  run.  Most 
often,  the  value  associated  with  the  quality  control  activity  should  be  higher  than  that  associated  with  the 
chemistry  control  activity.  This  is  because  it  is  important  to  know  what  is  in  each  steel  slab  that  is  sold.  In 
fact,  since  many  customers  will  not  buy  a  slab  without  detailed  knowledge  of  its  chemistry’,  the  profit  that 
would  be  realized  from  the  slab  is  at  stake  if  the  tracking  activity  does  not  execute  in  time.  On  the  other 
hand,  if  the  chemistry  control  activity  is  not  executed,  the  chemistry  of  the  steel  may  be  different  from  what 
was  intended.  This  is  acceptable  if  the  resultant  chemistry  is  one  that  can  be  sold  or  can  be  further 
processed  to  obtain  such  a  chemistry.  Notice  that  the  chemistry  —  even  if  it  is  not  the  chemistry  that  was 
onginally  intended  —  is  known  and  can  be  tracked  by  the  quality  control  activity. 

The  dynamic  nature  of  value  assignments  is  shown  by  the  fact  that  the  above  generalization  does  not  hold 
in  every  case.  When  a  particularly  rare  chemistry  is  desired,  it  is  sometimes  the  case  that  the  steel  cannot 
be  sold  if  the  chemistry  is  not  exactly  right,  therefore  placing  the  profit  for  the  heat  in  jeopardy  if  the 
chemistiy  control  activity  is  not  run.  It  is  possible  that  the  profit  involved,  especially  for  a  specialty  steel, 
will  outweigh  the  profit  that  will  result  from  tracking  steel  slabs  of  more  typical  chemistnes  through  the 
rest  of  the  mill.  Since  these  decisions  vary  with  each  heat  (mix)  of  steel,  values  must  be  assigned  to  the 
chemistry  control  and  quality  control  tracking  activities  dynamically  to  correspond  to  each  heat. 

Miltiary  defense  systems  arc  a  second  class  of  applications  that  seem  to  allow  values  to  be  assigned  to 
component  activities  meaningfully  and  would  benefit  by  using  a  scheduler  that  maximized  accrued  value 
for  the  application.  In  this  case,  the  value  accrued  for  an  activity  controlling  a  defense  system  would  be 
denved  from  the  number  of  lives  or  the  number  of  other  military  assets  that  can  be  saved  As  unsettling  as 
it  is  to  consider,  it  seems  wise  to  employ  a  scheduler  that  maximizes  the  number  of  lives  or  assets  that  arc 
successfully  defended. 
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These  examples  make  use  of  the  fact  that  there  is  a  common  "currency"  in  which  values  can  be  expressed 
naturally  —  money  in  process  control  situations  and  lives  or  other  military  assets  in  combat  systems.  In 
such  situations,  it  is  relatively  straightforward  to  assign  values  to  various  activities8.  Other  applications 
may  require  that  values  take  into  account  a  number  of  different  factors  —  money,  lives,  operator 
satisfaction,  and  so  forth  —  and  appropriate  weightings  of  these  factors  will  have  to  be  developed  to 
produce  acceptable  and  meaningful  activity  values. 

Of  course,  the  real  test  of  the  utility  of  this  approach  will  come  in  the  future  when  scheduling  algorithms 
that  maximize  application-defined  value  are  employed  in  production  systems  —  or,  perhaps,  prototype 
versions  of  production  systems.  At  that  time,  the  performance  of  these  systems  can  be  compared  directly  to 
alternative  approaches.  Pending  the  outcome  of  such  tests,  it  does  seem  to  be  useful  to  explore  the  notion 
of  maximizing  the  value  for  an  application. 

1.4.2.  Time-Value  Functions 

As  shown  in  the  above  discussion,  the  notion  of  assigning  values  to  application  activioes  and  scheduling 
activities  to  maximize  the  accrued  value  for  the  entire  application  has  merit  in  a  wide  range  of  applications. 
These  assigned  values  reflect  the  relative  importances  of  the  activities  that  they  represent 

Since  the  systems  under  consideration  for  this  work  are  real-time  systems,  the  value  associated  with  the 
completion  of  a  computation  vanes  as  a  function  of  time.  For  example,  in  an  automated  assembly 
application,  the  value  of  closing  a  mechanical  manipulator  to  gTasp  a  pan  on  an  assembly  line  is  a  function 
of  time.  If  the  grasping  motion  is  completed  too  soon,  the  part  will  not  have  reached  the  manipulator  yet. 
If  the  grasping  motion  is  completed  too  late,  the  part  will  have  already  passed  by  the  manipulator 

Time-value  functions  facilitate  the  description  of  the  time  constraints  and  relative  importances  of  the 
activities  comprising  a  real-time  application  The  time-value  function  records  the  value  to  be  accrued  by 
completing  the  designated  compuauonal  phase  at  each  point  in  time. 

Time-value  functions  seem  to  be  a  fairly  natural  expression  of  the  utility  of  completing  a  given 
computauon  as  a  function  of  time  in  many  situations.  A  skilled  operator  in  a  process  control  environment 
or  a  carefully  constructed  functional  requirements  document  for  the  system  will  often  be  capable  of 
describing  all  of  the  information  encoded  in  a  time-value  function. 

Although  time-value  functions  are  a  relatively  new  formalism  for  expressing  the  relative  urgency  and 


*Thu  »cl  of  usignmg  values  to  specific  activities  comprising  an  application  corresponds  roughly  to  the  normal  assignment  of 
priorities  to  activities  (where  the  activities  are  often  called  processes  or  tasks).  In  many  modem  applications  a  number  of  activiues 
coordinate  to  provide  a  single  application -level  logical  function,  such  as  material  tracking  In  such  systems.  some  activities  may 
provide  a  specific  service,  such  as  accessing  a  tracking  database,  to  a  number  of  other  activities  with  widely  varying  values  The 
assignment  of  a  single  value  to  the  se.ver  acuviry  ls  difficult.  If  it  has  a  lower  value  than  die  activity  thal  u  is  currently  serving,  then  it 
may  not  be  scheduled  as  quickly  as  it  should  be.  On  the  other  hand,  if  it  has  a  higher  value  than  the  activity  it  is  serving,  then  it  may 
consume  resources  that  could,  and  should,  be  used  by  other  activities  This  problem  is  allrviaird  if  an  approach  is  taken  where  the 
activities  in  the  computer  application  can  coirespond  directly  to  the  application  level  logical  functions,  while  still  providing  for 
modular  construction  of  the  application.  This  has  been  done  in  the  Alpha  Operating  System 
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importance  of  each  activity  in  a  real-time  system,  they  are  beginning  to  make  the  transition  into  pracnce 
and  have  been  used  successfully  in  a  few  selected  contexts, 

1.5.  Technical  Approach 

The  technical  approach  described  in  this  section  has  been  adopted  in  order  to  carefully  address  the 
problem  of  scheduling  with  dependencies  and  to  explore  and  evaluate  potential  solutions.  Bneflv,  the 
approach  consists  of  the  following  major  steps: 

1.  define  a  computational  model  within  which  to  work; 

2.  devise  an  algorithm  that  possesses  the  required  properties  and  express  it  within  the 
computational  model; 

3.  insofar  as  possible,  demonstrate  analytically  the  correctness,  utility,  and  tractability  of  the 
algonthm; 

4.  simulate  the  performance  of  the  algorithm  on  common  classes  of  supervisory  control  systems 
and  compare  v  th  other  relevant  algorithms  or  ideals. 

1.5.1.  Define  Model 

The  first  step,  defining  a  computational  model,  is  intended  to  provide  a  clear,  useful  framework  that  will 
capture  the  essential  aspects  of  the  problem  to  be  solved  and  will  also  support  the  specification  of 
unambiguous  solutions,  embodied  pnmanly  as  scheduling  algorithms.  The  need  for  a  model  that  exhibits 
all  of  the  desired  problem  features,  while  excluding  all  factors  that  are  non-essential  for  the  problem 
statement  and  solution  is  obvious.  If  the  work  is  done  with  the  simplest  model  that  accurately  expresses  the 
problem,  then  the  work  will  be  more  comprehensible  and  succinct.  Equally  important  is  the  requirement 
that  the  model  support  the  unambiguous  specification  of  scheduling  algorithms.  Without  such  definitions, 
the  ability  to  perform  precise/definitive  analytic  proofs  to  demonstrate  properties  of  an  algorithm  will  be 
lost  Also,  a  set  of  requirements  for  problem  solutions  is  formulated  in  terms  of  the  computational  model. 

1.5.2.  Devise  Algorithms 

After  the  model  has  been  created,  it  is  possible  to  begin  exploring  various  algorithms  within  the 
framework  provided  by  the  model.  While  the  computational  model  is  intended  to  support  the  development 
of  a  number  of  scheduling  algorithms  and  will  provide  an  excellent  platform  for  the  extension  of  this  work 
in  the  future,  this  thesis  does  not  explore  a  wide  range  of  alternative  algorithms  exhaustively.  Rather,  it 
identifies  and  characterizes  the  behavior  and  performance  of  a  single  algonthm  that  has  the  desired 
properties,  called  the  Dependent  Activity  Scheduling  Algonthm  (DASA).  This  algonthm  will  be  desenbed 
in  two  forms  —  a  formal,  mathemaucal  form  that  will  be  used  to  define  the  algonthm  and  to  support 
analytic  proofs  and  a  procedural  form  to  provide  a  measure  of  the  algonthm 's  complexity  and  to  support 
the  simulation  work  that  has  been  done.9 


9  Actually.  the  mathematical  definition  features  norwietrrminjsm  m  certain  places,  indicating  that  ordering  is  unimport  -it  with 
respect  to  the  algorithm  at  those  points  The  procedural  definition,  however,  does  not  contain  any  non-determinism  and  sc  >an  be 
viewed  as  ■  single  specific  implementation  of  the  aJgonthm  that  the  mathematical  definition  describes. 
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1.5.3.  Prove  Properties  Analytically 

Once  the  DASA  algorithm  has  been  defined,  analytic  proofs  that  demonstrate  that  it  satisfies  the  problem 
requirements  may  be  devised.  The  formal  model  that  is  used  to  describe  the  scheduling  algorithms  is  based 
on  automata  that  accept  certain  sequences  of  scheduling  events.  There  is  a  different  automaton  associated 
with  each  distinct  scheduling  algorithm.  So.  for  example,  the  automaton  associated  with  the  DASA 
algorithm  will  accept  any  sequence  of  scheduling  events  that  is  consistent  with  the  behavior  of  the  DASA 
algorithm.  Such  automata  can  also  accumulate  the  value  assigned  to  an  execution  history.  By  comparing 
the  execution  histories  accepted  by  the  automata  corresponding  to  different  scheduling  algorithms,  proofs 
can  be  constructed  that  show  that  two  scheduling  algorithms  accept  different  histories.  Furthermore,  the 
proofs  may  compare  the  values  accumulated  ior  all  of  the  execution  histories  accpeted  by  the  automata 
representing  certain  scheduling  algorithms  for  a  specific  set  of  phases  with  specific  time-value  functions 
and  computation  time  requirements.  (Taken  together,  these  last  two  items  —  a  phase's  time-value  function 
and  its  compulation  time  requirement  —  are  referred  to  as  the  phase’s  scheduling  parameters.)  Such 
comparisons  can  be  used  to  demonstrate  that  one  scheduling  algorithm  is  capable  of  generating  schedules 
that  are  superior  to  those  of  another  algorithm,  measured  in  terms  of  total  value  accrued  by  the  application 
during  its  execuuon  history. 

Unfortunately,  real-time  systems  featuring  complex,  dynamic  dependency  relationships  are  quite 
complex.  And,  although  the  analytic  proofs  can  make  some  observations  about  the  correctness,  behavior, 
and  value  of  the  algorithm,  a  complete  case  for  its  utTity  cannot  be  made  without  demonstrating  its 
performance  under  realistic  conditions.  To  address  this  need,  simulations  have  been  carried  out  to 
investigate  the  performance  of  the  DASA  algorithm  and  to  demonstrate  properties  that  cannot  be  proven 
analytically. 

1.5.4.  Simulate  Algorithm 

A  parameterized  workload  has  been  devised  that  can  mimic  various  numbers  of  activities  displaying  a 
range  of  access  patterns  to  a  set  of  shared  resources.  Using  this  workload,  a  suite  of  simulations  has  been 
run.  These  simulauons  compare  the  benefit  of  using  the  DASA  algorithm  instead  of  a  more  standard 
algorithm  —  for  instance,  a  static  priority  or  deadline  scheduling  algorithm  with  FIFO  queueing  for  access 
to  each  shared  resource.  They  also  compare  DASA’s  performance  with  a  reasonable  estimate  of  the 
theorerucal  maximum  value  that  can  be  obtained  The  DASA  scheduling  algorithm  is  relatively  complex 
when  compared  to  more  standard  scheduling  algorithms  Consequently,  in  a  uniprocessor  implementation 
of  the  algorithm,  DASA  will  require  more  time  to  select  an  activity  to  execute  than  a  more  standard 
algorithm  would.  In  order  to  be  fair  in  performing  compansons  among  scheduling  algorithms,  this 
additional  overhead  is  also  taken  into  account.  The  simulation  results  reveal  situations  in  which  applying 
the  DASA  algorithm  will  probably  be  profitable. 
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Chapter  2 

The  Scheduling  Model 


Models  are  central  to  abstract  study.  They  allow  the  salient  features  of  a  potentially  complex  system  to 
be  isolated  and  restrict  the  size  of  the  space  of  possibilities  to  be  investigated.  Properly  specified,  a  model 
provides  an  unambiguous  deSnition  of  the  behavior  of  a  system  and  highlights  the  underlying  assumptions 
that  are  made  by  the  investigator.  Within  the  framework  of  the  model,  simulations  and  analytic  analyses 
may  be  performed. 

To  take  advantage  of  all  of  these  properties,  a  model  has  been  devised  that  possesses  the  necessary 
richness  and  within  which  scheduling  algorithms  can  be  studied.  This  chapter  presents  this  model  and 
describes  the  rationale  that  shaped  it 

A  formal  computational  model  has  been  constructed  to  facilitate  the  definition  and  faunal  analysis  of 
scheduling  algorithms.  Initially,  this  model  is  presented  informally  in  order  to  allow  for  a  natural 
discussion  of  the  issues  that  shape  the  model  and  the  intended  structure  of  the  model  and  the  environment 
provided  by  real-time  applications  This  is  followed  with  a  formal  descripnon  that  provides  a  detailed, 
precise  specification  of  the  model. 

2.1.  Informal  Model  and  Rationale 

The  informal  discussion  of  the  computanonal  mode!  will  describe  each  of  the  principal  elements  of  the 
model  in  general  terms.  This  should  allow  the  reader  to  have  an  intuitive  grasp  of  the  interplay  of  various 
elements  of  the  model  without  having  to  wade  through  a  mass  of  symbols  and  mathematics.  This  will  set 
the  stage  for  the  presentation  of  the  formal  model,  where  all  of  the  details  will  be  specified  for  each  of  the 
principal  elements  of  the  model. 

2.1.1.  Applications,  Activities,  and  Phases 

As  mentioned  in  the  previous  chapter  (in  Sections  1.1  and  1.2),  an  application  is  composed  of  a  set  of 
activities.  Each  activity,  in  turn,  comprises  a  sequence  of  computational  phases,  and  each  computational 
phase  is  characterized  by  a  time-value  function  that  indicates  the  importance  and  urgency  of  that  phase.  At 
any  given  time,  an  activity  is  operating  in  a  single  computanonal  phase  so  that  the  activity  can  be  uniquely 
identified  by  designaung  the  phase  that  is  currently  underway.  Therefore,  the  complete  set  of  acuvities  can 
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always  be  represented  by  the  set  of  phases  currently  in  progress10,  and  this  set  can  be  designated  as: 

! Po'Pi'Pz'  '  l 

The  execution  of  an  application  involves  sharing  the  single  processor  among  the  set  of  active  phases  over 
time.  The  determination  of  which  phase  to  run  at  any  given  time  is  made  by  the  scheduler,  one  of  the  major 
components  of  the  operating  system,  based  on  the  relevant  information  available  to  it. 

2.1.2.  Shared  Resources 

Phases  may  access  shared  resources.  A  request  for  such  access  is  signalled  by  a  phase  by  means  of  a 
'request'  event  for  the  specific  resource  desired.  Permission  to  access  a  shared  resource  is  given  to  the 
phase  by  means  of  a  'grant'  event. 

All  shared  resources  that  are  held  by  an  activity  must  be  released  at  the  completion  or  abortion  of  each 
computational  phase.  This  assumption  is  jusufiable  on  two  counts,  but  may,  at  the  same  time,  seem  to  be 
restrictive.  First  of  all,  when  a  phase  represents  a  distinct  logical  stage  in  a  computation,  there  is  good 
reason  for  expecting  that  the  resources  used  to  carTy  out  that  phase  may  be  released  upon  its  completion. 
Of  course,  if  phases  are  used  to  represent  very  fine  grained  portions  of  a  computation,  then  this  assumption 
may  be  called  into  question.  However,  since  each  phase  is  a  unit  of  computation  that  corresponds  to  a 
single  time-value  function,  and  since  the  time  constraints  that  dictate  the  time-value  functions  are  derived 
by  the  physical  necessity  of  completing  a  compulation  in  a  certain  ume  frame,  it  seems  clear  that  using 
phases  to  delimit  very  small  portions  of  an  activity  departs  from  the  expected,  and  useful,  application  of 
phases  to  decompose  activities  in  a  real-time  system. 

The  existence  of  stylized  applications  or  system  facilities  gives  rise  to  the  second  justification  for  the 
assumption  that  all  shared  resources  are  released  at  the  completion  of  a  computational  phase.  One  specific 
example  of  such  an  application  is  an  atomic  transaction  facility.  The  use  of  transactions  in  real-time 
systems  is  appealing,  but  the  question  of  how  to  schedule  them  is  unsolved.  By  allowing  this  model  to 
capture  the  behavior  of  transaction  facilities  as  well  as  the  assumed  normal  behavior  of  real-time  activities, 
the  work  presented  here  can  hopefully  make  a  somewhat  greater  contnbution. 

2.1.3.  Phase  Preemption 

At  any  given  time  there  is  one  phase  that  is  actively  executing  on  the  processor.  That  phase  may  be 
preempted  by  the  scheduler  at  any  time.  A  preemption  is  signalled  by  a  '  preempt-phase'  event  Should  the 
scheduler  subsequently  determine  that  the  phase  should  be  resumed,  it  would  issue  a  'resume-phase'  event. 


°For  the  purpose*  of  this  model  *  phase  11  considered  to  be  "in  progress”  u  soon  is  u  is  mide  known  to  the  operiting  system  So, 
for  instance.  a  pha*e  that  has  never  executed  a  ungle  instruction  of  its  code  is  nonetheless  considered  to  be  in  progress  —  it  ha* 
progressed  far  enough  to  submit  its  initial  resource  request  (in  terms  of  required  processing  Ume.  importance,  and  urgency)  to  the 
system. 
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2.1.4.  Phase  Abortion 

The  scheduler  may  decide  to  abort  a  computational  phase  at  any  time.  This  is  indicated  by  issuing  an 
'abort-phase'  event  for  the  phase  to  be  aborted.  A  phase  might  be  aborted  to  free  a  shared  resource  more 
quickly  than  it  would  otherwise  be  freed.  Or,  a  transaction  facility  might  issue  an  abort  m  response  to  a 
component  failure  or  to  resolve  a  detected  deadlock. 

The  amount  of  time  required  to  completely  process  an  abort  depends  on  the  number  and  type  of  resources 
held  by  the  phase  being  aborted.  Each  time  access  to  a  new  shared  resource  is  granted  to  a  phase,  the 
amount  of  time  required  to  abort  the  phase  is  incremented  by  an  amount  dependent  on  the  newly  granted 
resource. 

The  incremental  amount  of  abort  time  associated  with  a  resource  may  arise  from  several  sources.  For 
instance,  for  resources  that  are  treated  like  data  objects  in  a  traditional  database  system,  each  data  object 
altered  during  the  course  of  an  aborted  transaction  must  be  returned  to  the  same  state  it  had  prior  to  the 
transaction.  The  time  required  to  restore  this  pre-transaction  state  is  determined  by  the  time  required  to 
find  the  desired  value  followed  by  the  time  required  to  actually  update  the  data  object. 

In  other  cases,  more  must  be  done  than  merely  restoring  the  state  of  the  appropnate  memory  locations. 
Real-time  systems  often  control  physical  processes  by  regulating  actuators  that  effect  changes  in  the 
physical  environment.  Permission  to  manipulate  an  actuator  may  be  acquired  by  successfully  requesting 
exclusive  access  to  a  shared  resource  that  is  logically  associated  with  the  actuator.  Once  access  to  the 
resource  has  been  granted,  the  actuator  is  available  to.  and  manipulated  by.  the  requesting  computational 
phase.  If  the  phase  is  subsequently  aborted  during  its  execuuon,  then  it  is  quite  possible  that  the  actuator 
may  have  to  be  manipulated  once  more  in  order  to  return  the  physical  environment  to  an  acceptable  state. 
The  amount  of  time  required  for  such  compensating  actions  must  be  included  m  the  time  allotted  for  abort 
processing  for  each  resource  of  this  type. 

Following  the  completion  of  an  abort,  the  effected  activity  will  be  ready  to  reexecute  the  aborted  phase  if 
time  and  resources  permit. 

2.]  A  F vents 

To  motivate  the  development  of  a  formal  model,  imagine  that  all  of  the  major  components  of  an  operating 
system  interact  by  signaling  specific  events  to  one  another.  Conceptually,  these  events  encapsulate 
information  and  commands,  and  they  can  originate  w-frhin  the  operating  system  or  from  the  computational 
phases  composing  the  application. 

As  shown  in  Figure  2-1,  each  event  includes  an  event  timestamp,  an  operation  name,  appropriate 
arguments  for  the  operauon,  and  the  onginator  of  the  event.  Timestamps  are  used  to  provide  a  globtil 
ordering  of  all  scheduling  events.  There  arc  a  small  number  of  scheduler-related  operations,  which  will  be 
described  below  And,  as  far  as  scheduling-related  events  are  concerned,  the  onginator  of  an  event  is  either 
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the  scheduler  itself  (meaning  that  the  event  passed  across  the  interface  from  the  scheduler  to  the  rest  of  the 
operating  system,  possibly  continuing  on  to  an  apphcanon  phase  i  or  an  individual  phase  (meaning  that  the 
event  passed  from  that  phase  to  the  scheduler,  via  the  operanng  system). 


‘cent  op(parms)  0 

where, 

t  is  a  timestamp, 

op  is  a  scheduling  operation  (as  defined  in  Fig.  2-4), 
parms  is  the  set  of  arguments  for  the  operation  op. 

O  is  the  onginator  of  the  event  (either  p,  for  a  phase,  or  S, 
for  the  scheduler) 


Figure  2-1:  Format  of  Scheduler  Events 


2.1.6.  Histories 

Given  this  model  of  operanng  system  structure,  an  observer  located  within  the  operating  system  could 
watch  an  application  execute  and  monitor  the  interface  between  the  scheduler  and  the  rest  of  the  operanng 
system,  (See  Figure  2-2.)  The  observer  could  then  record  a  sequence  of  timestamped  events  passing  across 
the  interface.  Conceptually,  these  events  would  represent  the  communicauon  of  informauon  and 
commands  to  and  from  individual  activity  phases  and  the  scheduler. 

Such  a  sequence  of  scheduling  events  is  called  a  history.  In  general,  any  sequence  of  scheduling  events 
constitutes  a  history,  although  not  all  histories  are  meaningful.  To  aid  in  recognizing  which  histones  are 
potentially  meaningful,  definitions  have  been  developed  for  well-formed  histories  (e  g.,  timestamps 
increase  throughout  the  history,  the  only  event  operations  included  in  the  history  arc  those  listed  in  Figure 
2-4i  and  for  legal  histones  (i.e.,  well-formed  where  the  sequence  of  events  us  plausible,  for  example, 

request's  precede  'grant's).  Operations  on  histones  have  also  been  defined  to  facilitate  their 
manipulanon.  For  simplicity,  the  only  histones  that  are  ever  dealt  with  in  formal  analysis,  after  the 
introducuon  of  these  dcfimuons,  are  legal,  well-formed  histones.  (The  definitions  referred  to  in  this 
paragraph  are  presented  in  Section  2J.2.8  ) 

Different  schedulers  will  select  different  acuvmcs  for  execution  based  on  the  relevant  scheduling 
parameters  for  each  phase  under  considerauon.  Consequently,  different  histones  will  be  generated  by 
different  schedulers,  even  though  they  may  be  execuiJig  the  same  application  under  the  same  conditions 
Examining  these  histones  allows  the  performance  and  behavior  of  the  schedulers  to  be  compared  and 
contrasted.  Formally,  the  histones  are  examined  by  a  special  type  of  finite  state  automaton,  called  a 
scheduling  automaton 
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Figure  2-2:  An  Observer  Monitoring  the  Scheduler  Interface 

2.1.7.  Scheduling  Automata 

Since  events  and  histories  have  been  defined  formally,  automata  can  be  created  that  recognize  legal 
histories  corresponding  to  various  scheduling  algorithms.  Such  an  automaton  is  called  a  scheduling 
automaton. 

Each  scheduling  automaton  incorporates  a  scheduling  algorithm.  The  automaton  accepts  —  that  is, 
recognizes  —  any  history  that  could  have  resulted  from  the  use  of  the  scheduling  algorithm  that  it 
embodies.  All  other  histories  contain  some  sequence  of  scheduling  events  that  could  not  possibly  have 
resulted  from  the  use  of  the  embodied  scheduling  algorithm  and  are  rejected  by  the  automaton. 

2. 1.7.1.  General  Structure 

Figure  2-3  shows  the  structure  and  the  internal  components  of  a  scheduling  automaton.  The  automaton 
examines  each  event  in  a  history  in  turn.  Each  event  is  either  accepted  or  rejected  If  any  individual  event 
is  rejected,  then  the  entire  history  is  rejected. 

Each  event  comprises  an  operation,  a  timestamp,  and  a  set  of  parameters  for  the  designated  operation. 
The  automaton  associates  a  precondiuon  with  each  type  of  event  operation  When  considering  an  event. 
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Figure  2-3:  Scheduling  Automaton  Structure 

the  automaton's  Operation  Selector  activates  a  test  that  determines  whether  the  precc  mti  'P  Cjjv  Ctaicd 
with  the  event's  operation  is  satisfied.  If  it  is,  then  the  event  is  accepted,  and  the  actions  specified  in  the 
postconditions  for  the  operation  are  performed.  If,  on  the  other  hand,  the  precondition  for  the  event's 
operation  is  not  satisfied,  the  event  —  and  hence  the  entire  history  —  is  rejected. 

This  is  illustrated  in  Figure  2-3.  The  diamond-shaped  boxes  represent  the  picconditions  associated  with 
the  n  event  operations  that  may  be  accepted  by  the  automaton.  In  a  manner  analogous  to  a  flowchart,  the 
diamond-shaped  boxes  have  two  possible  outcomes,  and  an  arrow  leaves  the  box  for  each  outcome.  If  the 
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precondition  test  fails,  the  arrows  marked  "f  indicates  that  the  history  is  rejected.  Otherwise,  the  arrow 
marked  indicates  the  the  postconditions  associated  with  the  operation  must  hold 

The  operation  preconditions  in  the  automaton  test  various  conditions.  These  conditions  may  involve  the 
values  of  the  automaton's  state  components,  the  event  timestamp,  or  the  parameters  for  the  event  operation 
in  question11.  The  state  components  constitute  the  internal  state  of  the  automaton  that  persists  across 
events.  On  the  other  hand,  the  information  contained  in  the  Event  Parameters  box  does  not  persist  from 
one  event  to  the  next  —  it  simply  represents  the  operation  parameters  and  the  timestamp  for  the  current 
event. 

The  availability  of  this  information  for  precondition  testing  is  shown  by  the  arrows  leading  from  the  State 
Components  and  Event  Parameters  boxes  to  each  precondition  box. 

The  postconditions  that  must  hold  after  an  event  has  been  accepted  may  change  some  of  the  state 
component  values,  as  indicated  by  the  arrows  leading  from  each  postcondition  box  to  the  State  Component 
box. 

If  all  of  the  events  in  a  history  have  been  accepted,  the  Operation  Selector  signals  the  final  step  —  shown 
as  a  single  box  containing  the  word  "accept”  —  to  declare  that  the  history  has  been  accepted. 

2.I.7.2.  Specific  Scheduling  Automata 

The  preceding  discussion  oi times  a  standard  automaton  framework  forexpressing  scheduling  algorithms. 
Each  instance  of  a  scheduling  automaton  for  a  specific  scheduling  algorithm  wn-Jd  specicialize  this  general 
form.  This  would  typically  involve:  (1)  the  alteration  of  the  preco^  .litions  and  postconditions  for  the 
operations  accepted  by  the  automaton;  (2)  the  addition  of  some  algorithm-specific  state  components;  and 
(3)  the  specification  of  a  function  that  would  select  the  phase  to  be  executed  at  times  dictated  by  the 
automaton's  postconditions  (or,  perhaps,  its  preconditions). 

It  is  largely  through  the  last  specialization  —  the  selection  function  definition  —  that  the  scheduling 
algorithm  embodied  by  the  automaton  is  manifest.  Different  algorithms  choose  successor  phases  according 
to  different  criteria.  (They  may  also  be  invoked  to  make  selections  at  different  times,  so  that  the  selection 
function  alone  does  not  completely  differentiate  all  schedulers.) 

The  Genera]  Scheduling  Automaton  Framework  is  shown  in  Appendix  A.  It  is  a  scheduling  automaton 
that  lacks  a  few  critical  pieces.  While,  it  displays  the  structure  of  a  scheduling  automaton  and  has  a  number 
of  state  components,  it  is  intentionally  general  and  does  not  embody  any  specific  scheduling  algorithm. 
Later  in  this  chapter  (in  Section  2.3.2),  portions  of  this  automaton  framework  will  be  examined  in  more 
detail. 

In  later  chapters,  specific  scheduling  automata  of  interest  will  be  tudied.  These  will  be  presented  as 


1  'in  principal,  the  originator  of  the  event  could  alio  be  tolled  by  d  -  p-econdmon.  but  this  has  not  proven  useful  to  date 
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extensions  or  specializations  of  the  General  Scheduling  Automaton  Framework,  sharing  us  structure  and  a 
superset  of  its  state  components. 

2.2.  Assumptions  and  Restrictions  of  Model 

The  computational  model  presented  is  quite  general.  In  oider  to  focus  on  the  questions  of  greatest 
immediate  interest  in  this  thesis,  a  few  simplifying  assumptions  have  been  made.  In  particular,  two  specific 
assumptions  should  be  stated  and  examined  at  this  point. 

First  of  all.  time-value  functions  are  resticted  to  be  simple  step  functions.  The  most  important  :s>ue  to  be 
studied  in  the  thesis  is  how  to  use  dependency  information  to  construct  a  schedule  that  maximizes  the  value 
that  an  application  accrues  without  spending  too  much  tame  performing  scheduling  decisions.  This  issue  is 
best  isolated  if  considerations  such  as  maximizing  the  value  attained  by  completing  a  phase  are  initially 
ignored  This  is  an  issue  that  should  be  dealt  with  in  the  future,  but  it  seems  like  a  second-order  effect  for 
most  systems. 

Secondly,  the  compute  time  required  by  an  activity  to  complete  a  computational  phase  :s  as  .timed  to  be 
known  accurately.  In  many  real-time  systems,  this  is  a  fairly  reasonable  assumption.  Adding  additional 
information  to  describe  the  actuai  distribution  of  computation  times  may  increase  the  quality  of  the 
scheduling  decisions,  but  it  will  also  involve  more  calculations  and  therefore  be  more  costly  For  the 
simple  types  of  computations  done  in  typical  supervisory  control  systems,  it  may  well  be  sufficient  to  take 
die  simpler  approach  first,  at  a  slightly  reduced  cost 


2  J.  Formal  Model 

In  order  to  provide  a  Precise  framework  in  which  to  discuss  scheduling  policies  for  real-ume  activities, 
die  following  formal  model  has  been  adopted.  It  accommodates  tlx:  aspects  of  the  problem  domain  that 
were  presented  in  Chapter  1  and  includes  all  of  the  ideas  discussed  informally  in  the  preceding  sections  of 
this  chapter. 

Before  discussing  the  model  itself,  the  notation  that  is  employed  is  described,  followed  by  definitions  of 
key  primitives  in  the  model.  Next,  the  formal  model  is  presented  in  depth.  I  "his  discussion  is  locused 
around  the  definition  of  the  General  Scheduling  Automaton  Framework  All  of  the  othe.  sched  :iing 
automata  referred  to  by  this  work  will  be  defined  with  respect  to  this  framework.  Finally,  a  number  of 
observations  concerning  the  formal  model  arc  outlined. 

2.3.1.  Notation  and  Definitions 

This  section  describes  the  notation  that  is  used  throughout  the  rest  of  this  arid  subsequent  chapters.  The 
notauon  is  explained  it  this  point  so  that  all  of  th_  discussion  that  follows  can  be  uiie.preited 
unambiguously. 
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Naming  Conventions  A  set  of  conventions  are  employed  in  defining  the  computational  model  and  the 
scheduling  automata1*: 

•  Identifiers  written  in  all  capital  letters  denote  domains  of  values  (e  g..  TIMESTAMP. 
BOOLEAN);  individual  values  from  these  domains  are  written  in  all  lower-case  letters  (e  g.,  t 
true) 

•  Each  scheduling  automaton  has  certain  state  components  associated  with  it;  these  are 
designated  by  identifiers  that  begin  with  a  single  capital  letter  followed  immediately  by  at  least 
one  lower-case  letter  (e.g..  Total,  AbortGock) 

•  If  an  automaton  accepts  an  event  in  a  history,  the  postconditions  associated  with  the  accepted 
event  hold;  when  these  postconditions  result  in  modifying  the  value  of  a  state  component,  the 
new  value  is  followed  by  an  apostrophe  (e.g.,  Gock’  =  Dock  +  1  means  that  the  new  value  of 
the  automaton  state  component  named  Gock  is  one  greater  than  the  old  value) 

Mode-Phase  Pairs.  Typically,  specifying  the  current  workload  of  the  processor  is  simply  a  matter  of 
naming  the  phase  that  is  being  executed  at  this  time.  However,  since  it  is  possible  to  execute  a  phase 
normally  or  to  abort  it.  it  is  necessary  to  refer  to  the  computation  being  performed  on  the  processor  at  any 
given  time  as  a  mode-phase  pair.  Such  a  pair  specifies  both  the  phase  that  is  being  executed  and  the  mode 
of  execution  (either  ’normal’  or  ’abort'),  and  it  is  written  as  an  ordered  pair  delimited  by  angle  brackets: 
<m,p>. 

Two  auxiliary  functions  exist  to  select  the  individual  fields  from  a  mode-phase  pair.  Specifically,  if 
mpp  =  <m,  p>,  then: 

Mode(mpp)=Mode(<mp>)=m 

Phase(mpp)=Phase(</n,p>)=p 

Time-Value  Functions.  The  simplified  time-value  functions  studied  in  this  work  are  described  as  step 
functions,  where  the  amplitude  of  a  function  indicates  the  value  of  completing  the  corresponding  phase  on 
time.  Let  the  time-value  function  for  phase  p  be  given  by: 

Valueip)  =  step(val,  tc) 
where, 

tc  is  the  critical  time,  or  deadline,  for  this  phase  of  an  activity, 

val  >  0,  is  the  value  associated  with  completing  a  phase  by  its  deadline, 

step(val,  tc)(t)  =  val ,  t  <  tc 

0,  1  >  tc 

Then  define  the  following  functions  that  select  parameters  from  the  simplified  time-value  functions: 
Deadlineip)  =  DUValueip))  =  DL(step(val.  tc))  =  tc 

Val(p)  =  V(Value(p))  =  V(step(val,  tc))  =  val 


l2Some  of  these  convenuons  end  much  of  the  notation  in  genera]  has  been  modeled  after  a  stale  used  h>  Maurice  1  lerlihy 
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23.2.  The  General  Scheduling  Automaton  Framework  (GSAP) 

The  General  Scheduling  Automaton  Framework,  expressed  within  the  formal  structure  described  in  this 
and  previous  sections,  provides  an  overall  specification  for  the  generic  scheduling  automaton.  .Although  it, 
in  fact,  embodies  no  specific  scheduling  algorithm  and  is  incompletely  specified  in  other  respects  as  well, 
the  automaton  framework  is  useful  because  all  of  the  automata  discussed  in  the  rest  of  this  work  are  denved 
by  modifying  it  in  relatively  minor  ways. 

in  the  following  sections,  formal  definitions  will  be  given  for  activities,  phases,  shared  resources,  events, 
operanons,  and  histones.  Within  this  context,  the  vanous  parts  of  the  General  Scheduling  Automaton 
Framew  ork  can  be  expressed  formally  as  well.  These  parts  include  the  automaton  state  components  and  the 
preconditions  and  postconditions  associated  with  the  operations  accepted  by  the  automaton. 

2J.2.1.  Applications  and  Activities 

.An  application  is  composed  of  a  set  of  activities,  each  of  which  comprises  a  sequence  of  computational 
phases.  At  any  given  tame,  these  activites  can  be  referred  to  by  means  of  the  phase  that  they  are  currently 
carrying  out.  Therefore  the  set  of  activines  can  be  represented  by  the  set  of  phases  currently  defined:  [p0, 
Pj.p2.  .  .  .  ) 

2 J.2.2.  Events  and  Histories 

Whde  executing  an  application,  an  observer  located  within  the  operating  system  could  monitor  a 
sequence  of  time-stamped  events  passing  to  and  from  the  scheduler.  These  events  are  of  the  form: 

‘rven,  Optparms)  O 

where, 

t  is  a  timestamp, 

op  is  the  operation  associated  with  the  event  fas  defined  below), 
parms  are  the  arguments  for  the  operation, 

O  is  the  onginator  of  the  event  (either/?,  for  a  phase,  or  S, 
for  the  scheduler) 

A  sequence  of  these  events  is  called  a  history.  Notice  that  some  of  these  events  are  generated  by  individual 
phases  and  some  are  generated  by  the  scheduler. 

2  J.2.3.  Operations 

The  operations  that  may  occur  in  events,  and  the  potential  originators  of  each,  are  show  n  in  Figure  2-4. 

The  general  meaning  and  usage  of  each  of  these  operations  may  be  stated  very  briefly: 

•  'request-phase  —  ends  one  computational  phase  and  desenbes  the  requirements  of  the  next 
atomically; 

•  ’abort-phase’  —  aborts  the  designated  phase,  returning  all  of  the  shared  resources  held  by  the 
phase  to  acceptable  states  for  use  by  other  phases; 

•  ’preempt-phase’  —  suspends  the  currently  executing  phase; 

•  ’resume-phase’  —  resumes  a  phase  that  had  previously  been  preempted; 
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Operation  Type 

Potential  Originatoris) 

request -phase(v.  t^^) 

Phase 

abort-phase(p) 

Scheduler  or  Phase 

preempt-phase(p) 

Scheduler 

resume-phase(p ) 

Scheduler 

request(r) 

Phase 

grant(p.  r. 

*urvto^ 

Scheduler 

where 

V 

*  expected 

P 

r 

^  undo 

is  a  time-value  function, 

is  the  time  required  to  execute  the  phase,  assuming  no 

waiting  must  be  done  to  acquire  shared  resources. 

designates  a  phase, 

designates  a  shared  resource,  and 

is  the  time  required  to  restore  a  shared  resource  to  its 

pre-grant 'ed  state 

Figure  2-4:  Operation  Types  and  Originators 

•  'request’  —  signals  a  request  for  access  to  a  shared  resource; 

•  'grant'  —  grants  permission  to  access  a  shared  resource. 

However,  the  precise  meaning  and  usage  of  these  operations  is  wholly  dependent  upon  the  scheduling 
displine  embodied  by  the  automaton.  For  instance,  one  automaton  (embodying  a  FIFO  or  priority 
scheduling  algorithm,  for  example)  may  deem  that  a  new  'request -phase'  event  may  be  signaled  by  the 
currently  executing  activity  at  any  time  and  that  the  activity  may  continue  executing;  while  another 
automaton  (embodying  the  DASA  scheduling  algonthm,  which  is  presented  in  Chapter  3)  may  require  that 
a  scheduling  decision  must  be  made  at  that  point,  possibly  resulting  in  the  execution  of  a  different  activity. 
Similarly,  the  rules  for  when,  and  even  if,  phases  may  be  preempted  or  aborted  may  vary  from  automaton 
to  automaton. 

Section  2.3.2.10  describes,  in  a  little  more  detail,  the  semantics  associated  with  these  operations.  Once 
again,  there  is  some  vagueness  due  to  the  fact  that  the  definition  is  couched  in  terms  of  an  automaton 
framework  and  not  a  true  automaton  instance.  In  Chapter  3,  specific  definitions  will  be  presented  for  the 
operations  accepted  by  the  DASA  Scheduling  Automaton. 
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2 .3.2.4.  Computational  Phases  of  Activities 

The  individual  computational  phases  that  comprise  an  activity  are  delimited  by  'request-phase'  events.  A 
'request-phase'  event  simultaneously  ends  one  computational  phase  of  an  activity  and  describes  the  known 
requirements  of  the  the  next  computational  phase. 

Each  phase  that  is  successfully  completed  contributes  value  to  the  overall  application.  That  value  is 
determined  by  evaluating  the  time-value  function  describing  the  phase  just  completed  at  the  time  of 
completion.  On  the  other  hand,  an  aborted  computational  phase  contnbutes  no  value  to  the  overall 
application  —  although  it  may  free  resources  that  allow  other  cnncal  phases  to  execute. 

2 _3 .2.5.  Shared  Resources 

Phases  m3y  access  shared  resources.  A  request  for  such  access  Ls  signalled  by  a  phase  by  means  of  a 
request'  event  for  the  specific  resource  desired.  Permission  to  access  a  shared  resource  is  signalled  to  the 
phase  by  means  of  a  'grant'  event. 

.All  shared  resources  that  are  held  by  an  activity  must  be  released  at  the  compleuon  or  abortion  of  each 
computational  phase. 

2.3.2. 6.  Phase  Preemption  and  Resumption 

At  any  given  time  there  is  one  phase  that  is  active,  it  may  be  preempted  by  die  scheduler  This  is 
signalled  by  a  '  preempt-phase'  event.  The  scheduler  may  subsequently  determine  that  the  phase  should  be 
resumed;  this  is  signalled  by  a  '  resume-phase'  event. 

The  computational  model  allows  a  phase  to  be  preempted  at  any  nme.  Individual  scheduling  algonthms 
may  restrict  this  by  only  allowing  preemption  at  spo  lfic  times  or  by  not  permiung  preemption  at  all.  This 
type  of  behavior  is  formally  described  in  the  precondition  of  live  'prcempi-phase'  event  opeiation  for  each 
specific  scheduling  automaton. 

2.3.2. 7.  Event  Terminology  and  Notation 

Some  additional  terminology  and  notation  will  be  useful  ior  discussing  events,  let  an  event.  <-  represent 
the  following  event: 

e  =  p( farms)  O 

Then  define  the  following  simple  funcuons: 
t.mestamp)  e>  =  t 

r\enl 

e\er,tr,pe\e)  -  op 


sourceie)  =  O 
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2  J.2.8.  Definitions  and  Properties  of  Histories 

Earlier,  a  history  was  defined  as  a  sequence  of  events.  Not  all  histones  are  meaningful  or  well-formed. 
Let  eQ,  e}.  e2  .  •  •  denote  events.  Then,  formally,  a  history,  H ,  can  be  denoted  as. 

H  =  e0  e\  e2'  ■■■  en 

where  the  operator  denotes  concatenation. 


Informally,  a  projection  of  a  history  selects  certain  events  from  a  history,  preserving  their  relative 
postions  in  the  projection.  Therefore,  a  projection  of  a  history  could  include  all  of  the  'request-phase's 
from  the  histpry  or  all  of  the  events  that  dealt  with  a  specfic  phase.  The  symbol  "|"  denotes  a  projection. 
So  for  example,  H  |  p  represents  the  projection  of  history  H  onto  phase  p.  This  projection  would  include  all 
of  the  events  that  were  originated  by  phase  p  or  that  were  originated  by  the  scheduler  and  included  p  as  an 
operational  parameter. 


The  conditions  that  define  a  well-formed  history  include13: 

•  event  timestamps  must  increase  monotonically  and  must  be  unique  —  test :  examine  the 
timestamps  on  events;  for  example,  apply  the  function  time  stamp  sOK{)  to  a  history  H  to  verify 
that  it  meets  this  requirement,  where  times  tamp  sOK{)  is  defined  as: 

time  stamp  sOK(t>)  =  timestampsOK(e)  =  true 
timestampsOK(e t  e2-H)  = 

false,  iinmestampiefi  >  timestamp(ef) 

t  imestampsOK(H) .  otherwise 

•  request  for  a  resource  must  appear  in  the  schedule  before  the  corresponding  grant  —  test:  for 
each  'grant'  event,  search  the  history  of  the  phase  in  which  the  grant'  occurred  for  a 
preceding  'request'  for  the  same  resource 

•  a  phase  cannot  be  preempted  if  it  is  not  active;  it  cannot  be  resumed  if  it  is  active;  and  so  on  — 
simple  tests  check  all  of  these  conditions 

•  a  given  phase  either  commits  or  aborts;  the  events  assure  that  a  singe!  phase  cannot  do  both, 
however,  a  well-formed  history  must  have  at  most  one  abort-phase'  event  for  any  given  phase 
—  test:  examine  the  history  for  the  occurance  of  two  or  more  abort-phase'  events  for  a  single 
activity  that  ore  not  separated  by  a  request-phase’  event. 

•  expected  compute  time  is  accurate  —  test:  check  that  the  estimated  computation  time  equals 
the  actual  computational  time  used,  for  example,  the  following  test  could  be  applied. 

cttestiH)  =  (d p)(compumeOK(H  |  p)  w phaseabor,ed(H  |  p) 
v phaseunfinished{H  \  p)) 

where, 


,}I.  it  no!  always  clear  that  a  specific  test  be  •  requirement  of  a  well-formed  history  or  whether  it  is  ■  requirement  that  determines 
which  histones  will  be  accepted  by  «  given  automaton.  There  is  no  question  that  the  proper  temporal  ordering  of  events  is  a 
requirement  for  a  well -formed  history;  however,  tests  that  constrain  the  relative  ordering  of  specific  events  —  for  instance,  request1 
and  grant'  events  —  in  a  history  are  not  so  obviously  requirements  for  a  well-formed  history  As  a  result,  this  list  is  merely  an 
attempt  to  lay  down  an  initial  set  of  tests.  Some  of  these  tests  need  not  be  done  prior  to  submitting  the  history  to  an  automaton  —  in 
those  cases,  the  automaton  will  enforce  the  requirements  verified  by  the  tests  in  question. 
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c  omptimeO  K(p  .6)  =  comptimeO  Kip  ,e)  =  0 
comptimeOKip.eye^ H)  = 

t2-t \+compttmeOK(H),  if t=r ,  resume-phaseip)  S 

ve,=f,  grantip )  S) 

M*2=t:  prrempt-phaseip)  5 

wel~h  rePuesl(r)  P ) 

if(e.={.  resume-phaseip)  5 

ve, =f,  grantip)  S) 
rv(e^=t2request-phase(v,t)  p 

vf, =(,  abort-phaseip)  O) 

phaseabortedip.O)  =  false 
phaseabortedip.e  If)  = 

true,  i[e=l  abort-phaseip)  O 

false,  request-phase(v.t2)  p 

phaseabortedipjd),  otherwise 

phaseunftrushedip.b)  =  /nre 

phaseurfimshedip.ehf)  - 

/aise,  if f=/  abort-phaseip )  0 

request-phase(v.t2)p 

phaseunfinishedipdl),  otherwise 

•  expected  abort  time  is  accurate  —  test  similar  to  the  previous  test 

•  estimated  computation  time  required  for  a  phase  must  always  be  greater  tfc  in  or  equal  to  zero14 
—  test:  straightforward  inspection  of  each  request-phase'  event  in  the  history 

•  no  request'  event  should  request  shared  access  to  the  nullresource  —  test .  straightforward 
inspection  of  each  request'  ev  ent  in  the  history 

232.9.  Automaton  State  Components 

The  state  components  associated  with  the  General  Scheduling  Automaton  Framework  are  shown  in 
Figure  2-5.  Each  component  and  the  range  of  values  it  may  take  on,  is  described  below. 

ExecMode,  ExecMode  is  a  relation  that  associates  an  execution  mode  with  each  phase.  At  any  given 
time,  a  phase  can  be  either  executing  normally  or  aborting.  Also  at  any  time,  a  normally  executing  phase 
can  be  aborted.  Once  an  abort  is  initiated,  it  must  be  completed  before  normal  execuuon  of  the  entire  phase 
can  again  be  attempted. 

ExecClock  and  AbortClock,  The  next  two  state  components  shown  in  Figure  2-5  are  used  to  track  the 
amount  of  time  required  to  complete  the  normal  execution  or  the  abortion  of  a  phase.  When  a  phase  is 
executing  normally,  the  relation  ExecClock  indicates  the  amount  of  processing  time  needed  to  successfully 

uAn  additionaJ  requirement  miy  also  be  placed  on  the  parameters  of  a  ' request  phase'  event:  the  value  function  must  be  of  the 
appropriate  form,  as  outlined  below.  This  requirement  has  not  been  included  tn  this  list  because  the  tests  that  are  present  all  apply  to 
the  general  case  of  scheduling  with  dependency  considerations  in  a  real-time  environment  using  information  available  from  arbitrary 
time -value  functions.  This  requirement  is  related  to  a  simplification  made  to  make  the  work  more  dear  and  more  manageable,  and  so 
does  not  seem  to  carry  the  came  weight  as  the  others  listed  above. 
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General  State  Components: 

•  ExecMode.  PHASE  ->  MODE  (MODE  is  either  ’normal'  or  ’abort’) 

•  ExecGock:  PHASE  VIRTU AL-TIME 

•  Abort  Clock:  PHASE  -*  VIRTUAL-TIME 

•  ResumeTime:  PHASE  -4  TIMESTAMP 

•  Value:  PHASE  -> (TIMESTAMP  ->  VALUE) 

•  Total:  VALUE  (initially  ’O’) 

•  RunmngPhase:  PHASE  (initially  ’nullphase’) 

•  PhaseElect:  MODE  x  15  PHASE  (initially  ’<normal,  nuilphase>’) 

•  PhaseList:  list  of  PHASE  (initially  ’6’) 

Domains  for  State  Component  Values: 

•  MODE:  normal  v  abort 

•  PHASE:  £  lp0,P],P2-  •  •  •  1  v  nullphase 

•  RESOURCE:  e  [r0,  rl'  r2'  •  •  •  1  v  nullresource 

•  TIMESTAMP:  real  number,  expressed  in  ticks  of  standard  clock 

•  VALUE:  real  number  >  0 

•  VIRTUAL-TIME:  real  number  >  0,  expressed  in  ticks  of  standard  clock 


Figure  2-5:  State  Components  of  General  Scheduling  Automaton  Framework 
complete  the  execution  of  that  phase.  Similarly,  when  a  phase  is  aborting,  AbortClock  indicates  the  amount 
of  processing  time  needed  to  complete  the  abort  proces.»u.g. 

At  the  start  of  a  new  phase.  ExecClock  associates  a  value  provided  by  the  activity  with  the  phase.  If  the 
phase  was  executed  in  isolation16,  ExecClock  speciGes  the  amount  of  lime  that  would  elapse  before  the 
phase  would  complete  executing.  Each  time  the  phase  executes,  the  value  of  ExecClock  for  that  phase 
decreases.  When  it  reaches  zero,  then  the  phase  has  completed  execution. 

On  the  other  hand,  AbortClock  represents  the  time  required  to  abort  the  current  phase.  In  addition,  the 
exact  length  of  time  required  to  abort  the  phase  depends  on  the  number  and  type  of  shared  resources  that  it 
has  acquired.  Therefore,  since  no  shared  resources  have  yet  been  acquired,  AbortClock  is  zero  at  the  start 
of  every  phase.  Subsequently,  after  any  shared  resource  is  requested  and  granted,  the  value  of  AbortClock 


!*This  designates  a  cross  produce  Thai  is,  PhaseElect  is  actually  a  mode  phase  pair,  as  described  in  Section  2.3  1 

'*By  executing  in  isolation,  contention  with  other  activities  for  both  processor  cycles  and  shared  resources  is  eliminated.  In  fact,  the 
phase  does  not  execute  in  isolation  and  these  factors  cannot  be  ignored  —  leading  to  this  scheduling  wort, 
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is  incremented  by  an  amount  that  is  a  function  of  that  resource.  This  amount  of  time  has  been  chosen  to 
allow  the  shared  resource  to  be  returned  to  an  acceptable  state  so  that  other  phases  may  use  it. 

ResumeTime.  ResumeTime  associates  with  each  phase  the  time  at  which  it  last  resumed  execution  This 
value  is  useful  in  keeping  the  values  of  ExecClock  and  AbortClock  accurate  for  the  executing  phase. 
Whenever  the  currently  executing  phase  is  surrendering  the  processor,  ResumeTime  can  be  compared  to  the 
current  time  to  determine  the  amount  of  computation  time  consumed  by  the  phase  —  thus  allowing 
ExzcClnck  or  AbortClock  to  be  updated,  depending  on  the  current  execution  mode. 

Value.  The  relation  Value  associates  time-value  functions  with  phases.  In  this  case,  the  time-value 
functions  are  themselves  represented  by  relations:  given  a  time,  a  time-value  relation  will  return  the  value 
accrued  by  completing  the  phase  at  that  rime.  As  stated  in  Section  2.2.  the  time-value  functions  considered 
in  this  work  are  simple  step  functions. 

TotaL  Total  accumulates  the  values  accrued  by  successfully  completing  phases.  Initially,  since  nothing 
has  been  accomplished.  Total  is  zero.  Then,  after  any  phase  is  successfully  completed,  the  amount  of  value 
indicated  by  the  phase’s  Value  relation  for  that  completion  time  is  added  to  Total. 

The  values  of  the  Total  state  components  of  two  different  scheduling  automata  that  have  v/orked  on  the 
same  application  can  be  compared  to  determine  which  yielded  a  higher  total  value  for  the  application. 
(This  fact  will  be  used  in  simulations  and  proofs  in  later  chapters  when  comparing  two  different  scheduling 
algorithms.) 

RunningPhase.  RunmngPhase  indicates  which  phase  is  currently  executing  on  the  processor.  If  no 
activity  is  currently  executing  —  as  is  the  case  initially  —  RunmngPhase  is  equal  to  nullphase. 

PhaseElect.  PhaseElect  also  indicates  a  phase.  In  this  case,  it  is  the  phase  that  should  be  executing  now. 
If  this  is  different  than  RunmngPhase ,  then  the  currently  executing  phase  should  be  suspended  and  replaced 
by  the  PhaseElect.  Once  again,  in  the  initially  empty  system,  PhaseElect  specifies  that  the  nullphase 
should  be  executed  normally. 

PhaseElect  names  net  only  the  phase  to  be  executed  but  also  the  execution  mode  for  the  phase. 

PhaseList.  Pha-eList  is  simply  a  list  that  containing  all  of  the  phases  known  to  the  automaton.  This  iisi 
changes  as  new  phases  arrive  and  old  phases  are  completed.  Initially,  since  there  are  no  phases  PhaseList 
is  empty. 

Automaton-Specific  State  Components.  Other  state  components  are  also  associated  with  an  automaton. 
These  are  used  to  handle  some  of  the  bookkeeping  details  for  the  specific  scheduler  being  used.  The 
components  that  appear  above  are  intended  to  reflect  the  state  that  any  specific  scheduler  would  need  and 
maintain  under  this  general  model. 

Specific  initial  values  may  be  given  to  many  of  these  state  components  in  order  to  satisfy  the 
requirements  of  a  given  automaton. 
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Domains  for  State  Component  Values.  The  domains  that  supply  the  values  for  the  state  components 
are  straightforward  and  are  shown  in  Figure  2-5  along  with  the  state  components  of  the  General  Scheduling 
Automaton  Framework.  The  domain  MODE  contains  only  two  values,  normal  and  abort.  The  domain 
PHASE  consists  of  all  of  the  phases  known  by  the  automaton  as  well  as  the  nullphase.  Similarly,  the  domain 
RESOURCE  consists  of  all  of  the  shared  resources  known  to  the  automaton  as  well  as  the  nullresource.  The 
values  from  all  of  the  time-value  functions  are  drawn  from  the  domain  value.  These  must  be  positive 
(according  to  the  assumptions  stated  earlier  in  Section  2.3.1)  and  are  chosen  from  the  real  numbers  so  that 
there  are  no  unnecessary  restrictions  placed  on  them.  The  domain  value  also  contains  zero  since  Total 
receives  its  value  from  this  domain  and  it  initially  has  no  accrued  value. 

Time  is  central  to  the  behavior  of  real-time  systems,  and  the  domain  timestamps  provides  a  source  of 
markers  in  time  for  the  automaton  to  use.  Each  timestamp  is  expressed  in  terms  of  ticks  of  a  standard 
clock.  The  ticks  of  this  clock  are  equally  spaced  in  time;  and  in  fact,  no'hing  in  the  model  prevents  the 
timestamps  from  taking  on  fractional  numbers  of  ticks  —  thus  allowing  arbitrarily  great  precision  to  be 
obtained  in  representation  of  times. 

The  other  domain  related  to  time  is  the  virtual-TIME  domain.  Values  from  this  domain  represent  time 
durations.  Once  again,  they  are  expressed  in  terms  of  ticks  of  the  standard  clock.  These  durations  are  used 
to  supply  values  for  state  components  like  ExecClock  and  AbortClock  where  only  non-negative  durations 
are  meaningful. 

2_3.2.10.  Operations  Accepted  by  GSAF  with  Preconditions  and  Postconditions 

The  operations  recognized  by  the  General  Scheduling  Automaton  Framework  are  shown  in  Figure  2-6. 
(Notice  that  this  figure  has  two  parts,  appearing  on  pages  C-34  and  C-35,  respectively.)  Minimal,  or 
skeletal,  precondiuons  and  postconditions  for  each  operation  are  included  in  the  figure. 

In  later  chapters,  some  specific  scheduling  automata  will  be  discussed  in  detail.  Each  discussion  will 
include  a  descnption  of  the  preconditions  and  postconditions  associated  with  the  operations  accepted  by  the 
automaton  under  consideration.  Consequently,  the  discussion  of  those  topics  in  this  section  will  be  brief. 
Only  the  highlights  and  general  structure  of  an  automaton's  operation  specification  will  be  addressed  here. 

Since  the  'request-phase'  event  denotes  the  initiation  of  each  computational  phase  of  every  application 
activity,  it  is  accepted  by  every  scheduling  automaton.  Furthermore,  its  precondition  is  simply  ” true ", 
indicating  that  new  phases  can  arrive  at  any  time.  This  does  not  necessarily  require  that  a  new  scheduling 
decision  must  be  made  upon  the  arrival  of  each  new  phase,  although  some  automata  may  do  just  that. 
Since  such  a  scheduling  decision  is  not  made  in  every  scheduling  automaton,  no  decision  is  made  in  the 
General  Scheduling  Automata  Framework. 

In  the  same  spirit,  the  postconditions  for  the  'request-phase'  event  include  only  those  conditions  that  will 
almost  certainly  belong  in  every  scheduling  automaton  of  interest  Those  postconditions:  (1)  accumulate 
any  value  accrued  from  completing  a  previous  computational  phase  of  the  same  activity;  (2)  initialize  the 
automaton’s  state  components  to  capture  the  new  phase’s  scheduling  parameters;  and  (3)  update  the  list  of 
phases  known  to  the  automaton  based  on  the  new  phase's  scheduling  parameters. 
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•  'even,  request-phasefv.  texpecled)  p: 

preconditions: 

tme  <No  preconditions  here  so  that  interrupts  and  other  new  phases 
can  occur  at  any  ume> 

postconditions: 

if  (RunningPhase  =  p)  then 

if  (ExecMode(p)  =  normal)  then 

Total’  =  Total  +  Value(p)(tevmt) 
else 

;no  value  for  aborted  phase 
.release  the  resources  acquired  during  the  phase 

;accept  values  for  scheduling  parameters 

Value’(p)  =  v 

ExecClock’fp)  =  texpecled 

AbortGock'(p)  =  0 

ExecMode'fp)  =  normal 

.note  that  p  is  not  resource-waiting 

;make  sure  p  is  part  of  the  list  of  phases,  if  necessary 

lf  (‘expected  >  °>  then 

PhaseList’  =  PhaseList  u  (Pi 

else 

PhaseList’  =  PhaseList  -  ( p } 

•  tnenl  abort -phase(p)  O: 

preconditions: 

<Specific  to  ike  scheduler  under  consideration* 
postconditions: 

ExecMode’fp)  =  abort 
ResumeTime’(p)  =  tevem 


Figure  2-6:  Operations  Accepted  by  General  Scheduling  Automaton 

Notice  that  value  is  accumulated  for  the  completion  of  a  previous  phase  only  if  the  currently  executing 
phase  issues  the  ‘request-phase’  event,  thereby  signaling  that  the  current  phase  has  completed  execution.  If 
some  other  activity  issues  the  ‘request -phase'  event,  it  is  signaling  the  existence  of  a  new  phase  to  the 
automaton  while  a  different  phase  is  executing,  so  no  phase  completion  has  occurred. 

In  addition,  no  value  is  accrued  for  a  phase  that  has  been  aborted.  If,  on  the  other  hand,  the  phase  has 
completed  successfully  the  value  accrued  is  determined  by  evaluating  its  time-value  function  at  the  time  of 
completioa 

Finally,  since  it  requires  a  positive  amount  of  time  to  accomplish  any  processing,  a  tcxprcled  parameter  that 
is  less  than  or  equal  to  zero  indicates  that  there  is  no  subsequent  computational  phase  for  the  activity 
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•  ! event  preempt -phase/ p)  S: 

preconditions: 

<Specific  to  the  scheduler  under  consideration 
postconditions: 

if  (ExecMode(p)  =  normal)  then 

ExecClock’fp)  =  ExecClock(p)  -  (tevem  -  ResumeTime(p)) 

else 

AbortQock'(p)  =  AbortClock(p)  -  (tevent  -  ResumeTime(p)) 

•  t  nl  resume-phase(p)  S: 

preconditions: 

<Specific  to  the  scheduler  under  consideration 
postconditions: 

ResumeTime’(p)  =  tevent 

•  ’event  redufs!(r)  p 

preconditions: 

<Specific  to  the  scheduler  under  consideration 
postconditions: 

ExecQock’fp)  =  ExecGock(p)  -  (tevent  -  ResumeTime(p)) 

•  ’event  grant(P ■  r-  undotime(r))  S: 

preconditions: 

<Specific  to  the  scheduler  under  consideration 
postconditions: 

ResumeTime'(p)  =  tevent 

AbortGock’(p)  =  AbortGock(p)  +  undotime(r)17 


Figure  2-6:  Operations  Accepted  by  General  Scheduling  Automaton,  continued 
issuing  the  ’request-phase’  event.  In  that  case,  the  phase  is  removed  from  the  PhaseList.  in  all  other  cases, 
the  phase  is  included  in  the  PhaseList. 

The  ’abort-phase’  event  in  the  General  Scheduling  Automaton  Framework  is  similar  to  the  remainder  of 
the  scheduling  events:  its  precondition  is  automaton-specific  and  its  postconditions  specify  bookkeeping 
that  must  be  done  in  the  event  that  the  event  occurs.  In  particular,  the  ’abort-phase’  event's  postconditions 
change  the  phase’s  execution  mode  to  abort  and  note  the  time  that  the  phase  began  aborting.  In  the  event 
of  a  preemption,  this  time  (ResumeTime)  will  be  consulted  to  adjust  the  phase's  AbortClock  to  indicate  the 
amount  of  time  required  to  compete  the  abort  processing,  which  will  be  used  in  subsequent  scheduling 
decisions. 


,7The  function  'undo'uneO'  indic*t£s  the  tmoum  of  time  th*t  will  be  required  to  restore  the  resource  just  acquired  to  an  acceptable 
stale  for  use  by  another  activity.  In  many  cases,  this  may  simply  involve  returning  the  resource  to  the  state  it  had  at  the  time  it  was 
acquired.  In  other  cases,  reluming  the  resource  to  any  of  a  number  of  semantically  equivalent  states  may  be  sufficient  or  actions  may 
have  to  be  performed  to  affect  the  physical  process  under  controlled.  The  actions  required  and  the  amount  of  time  they  will  take  may 
vary  from  system  to  system  and  from  application  to  application.  Consequently,  for  the  purposes  of  this  work,  they  have  been  cast  as  a 
function  that  acts  to  indicate  their  role  without  applying  a  single  definition  across  ail  resources  or  applications. 
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The  'preempt-phase'  event  has  an  automaton-specific  precondition.  It;  postconditions  handle  the 
bookkeeping  associated  with  preempting  the  executing  phase.  Specifically.  ExecClock  or  AbortCio-k  is 
updated  to  reflect  the  amount  of  time  still  required  to  complete  the  normal  or  abort  processing  of  the  phase, 
respectively.  This  is  accomplished  by  subtracting  the  amount  of  time  the  phase  had  executed  pnor  to  the 
preemption  from  the  amount  of  time  it  still  needed  to  complete  processing  before  it  began  that  execution. 

A  'resume-phase'  event  is  used  to  resume  execution  of  a  phase  that  had  been  suspended  b>  a  preempt- 
phase'  event.  The  'resume-phase'  event,  which  has  an  automaton-specific  precondition,  simply  notes  the 
time  at  which  the  designated  phase  resumed  executioa  This  time  is  used  to  adjust  the  state  components 
dealing  with  the  required  execution  time  of  the  phase  whenever  the  phase  is  subsequendv  preempted. 

Once  again,  the  'request'  event  has  an  automaton-specific  precondition.  Its  postcondition  updates  the 
appropriate  state  component  clock  for  the  phase,  depending  on  its  execution  mode.  This  is  done  to 
facilitate  the  use  of  a  scheduling  decision  as  a  result  of  a  request  for  a  shared  resource.  The  updating  of  the 
relevant  state  components  ensures  that  the  automaton  will  make  a  decision  based  on  the  most  up-to-date 
information. 

The  'grant'  event,  which  also  has  an  automaton-specific  precondition,  notes  the  time  at  which  the  phase  is 
awarded  the  shared  resource  it  had  previously  requested  and  begins  execution.  Another  postcondition 
increments  the  AbonClock  state  component  for  the  designated  phase  to  reflect  the  amount  of  time  that  will 
be  required  to  return  the  shared  resource  to  an  acceptable  state  for  another  phase  in  the  event  that  the 
current  phase  is  aborted.  This  length  of  time  may  vary  from  resource  to  resource,  and  so  is  denoted  as 
undonmeir),  a  function  of  the  resource  in  question. 

Although  the  'request'  and  'grant'  phase  events  behave  as  if  the  processor  is  surrendered  after  each 
request,  this  does  not  have  to  be  the  case.  The  'request'  event  can  be  immediately  followed  by  the 
corresponding  'grant'  event  to  model  the  situation  in  which  the  processor  is  not  surrendered. 

Typeface  Convention.  In  the  definition  of  the  GSAF,  all  of  the  operation  definitions  —  their 
preconditions  and  postconditions  —  have  been  presented  with  a  roman  (normal)  typeface.  In  the  future, 
when  automata  are  presented,  those  parts  that  are  common  with  the  GSAF  will  continue  to  be  written  in  a 
roman  typeface.  However,  those  pans  that  are  different  will  be  wntten  in  an  italic  typeface.  Hopefully, 
this  will  allow  the  reader  to  focus  on  those  parts  of  the  definition  that  arc  different  from  the  general 
framework. 

2.3.2.11.  Active  Phase  Selection 

Although  the  General  Scheduling  Automaton  Framework  contains  state  components  and  will  accept  some 
scheduling  events,  it  is  not  really  a  scheduling  automaton.  Rather,  it  is  a  framework:  a  skeleton  that  has 
most,  but  not  all,  of  the  elements  of  a  scheduling  automaton.  For  instance,  as  was  discussed  in  the  previous 
section  (Section  2.3.2.10),  most  of  the  preconditions  for  acccpung  various  scheduling  events  arc 
unspecified  in  the  General  Scheduling  Automaton  Framework.  Also,  while  some  postconditions  have  been 
specified,  they  have  not  been  completely  specified. 
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Another  of  the  more  noticeable  omissions  in  the  specification  of  the  General  Scheduling  Automaton 
Framework  is  the  lack  of  a  function  to  ‘••elect  tire  next  phase  to  execute.  Furthermore,  not  only  is  this 
function  not  specified,  the  places  in  the  automaton  where  it  is  to  be  invoked  are  also  unspecified.  This  is 
because  different  schedulers  invoke  this  '’unction  at  different  times.  Therefore,  there  is  no  canonical  set  ot 
limes  (corresponding  to  a  fixed  set  of  points  in  the  General  Scheduling  Automaton  Framew  ork)  where  all 
scheduling  algorithms  invoke  a  phase  selection  function.  As  a  result,  this  has  beeD  omitted  from  the 
General  Scheduling  Automaton  Framework,  which  acts  as  a  lowest  common  denominator  of  sorts  among 
instance  of  scheduling  automata. 

To  illustrate  this  point,  consider  two  simple  scheduling  algonthms:  FIFO  scheduling  and  priority 
scheduling.  Whenever  a  new  computational  phase  enters  the  system  —  as  indicated  by  a  new  ’request- 
phase’  event  —  the  FIFO  scheduling  automaton  will  note  that  fact,  but  will  not  invoke  a  phase  selection 
function  to  determine  what  phase  to  execute.  It  simply  allows  the  currently  executing  phase  to  proceed 
until  it  gives  up  the  processor. 

On  the  other  hand,  the  priority  scheduling  automaton  will  make  a  new  determinauon  concerning  which 
phase  to  execute:  if  the  new  computational  phase  has  a  higher  priority  than  the  currently  executing  phase, 
then  the  active  phase  is  preempted  in  favor  of  the  new  phase. 

More  complex  scheduling  algorithms  may  evaluate  the  phase  selection  function  at  other  times  as  well 
For  instance,  toe  DASA  algorithm  described  in  Chapter  3  invokes  the  phase  selection  function  whenever  a 
shared  resource  is  requested  by  any  phase.  It  is  also  conceivable  that  there  are  schedulers  that  might  select 
which  phase  to  run  asynchronously  with  respect  to  the  given  set  of  scheduler  operations.  For  example,  a 
round  robin  scheduler  that  gave  each  phase  a  turn  by  offering  it  a  time-slice  would  make  preemption 
decisions  following  evenly  spaced  clock  interrupts.  To  accommodate  such  extensions,  new  scheduling 
operations  would  have  to  be  added  to  the  model  While  that  is  straightforward,  it  is  not  required  to 
investigate  the  algonthms  of  interest  for  scheduling  supervisory  control  systems,  and  so  it  would  only  serve 
to  complicate  the  model.  Consequently,  the  scheduling  operations  included  in  the  model  represent  a 
minimal  set  that  captures  all  of  the  relevant  behavior  within  supervisory  control  systems. 

2  J.3.  Notes 

A  few  fairly  minor  facts  can  he  noted  concerning  the  GSAF  framework  The  following  paragraphs 
address  some  of  them.  Most  of  them  explain  how  facets  of  real  applications  are.  or  can  be,  reflected  in  the 

formal  model. 

2.3 .3.1.  Manifestation  of  Assumptions  and  Restrictions 

Section  2.2  describes  the  specific  assumptions  3'  1  restrictions  that  arc  employed  in  this  work.  A  look  at 
the  GSAF  framework  will  reveal  how  those  assumptions  arc  manifest 

The  first  assumption  stated  dial  all  time-value  functions  are  restricted  to  be  simple  step  functioas.  The 
defimuon  provided  for  time-value  functions  in  the  model  in  Section  2.3.1  captures  that  assumption  directly. 
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are  often  not  explicitly  recognized  as  scheduling  events.  Specifically,  the  resource-related  events  — 
'request'  and  'grant'  —  are  directly  presented  to  the  scheduler  because  they  may  well  result  iD  new 
scheduling  decisions. 

This  should  be  contrasted  with  many  other  models  and  operational  systems.  There,  there  are  two  separate 
operating  system  facilities:  a  scheduler  and  a  resource  manager.  (See  Figure  2-7.)  The  resource  manager 
may  be  representing  one  or  more  actual  system  managers  —  the  lock  manager  and  the  semaphore  manager, 
for  instance. 


Integrated  Scheduler  & 
Resource  Manager 


Figure  2-7:  Organizations  of  Scheduling  Functions 

The  difference  in  organization  is  often  significant.  When  there  are  separate  managers  handling  access  to 
resources,  they  will  often  make  implicit  scheduling  decisions  that  are  not  in  keeping  with  the  overall  goals 
of  a  real-time  system  For  example,  resource  managers  may  service  resource  requests  in  a  first-come-first- 
serve  manner  In  that  case,  a  request  may  be  placed  in  a  FIFO  (first  in,  first  out)  queue  if  the  desired 
resource  is  not  currently  available.  As  a  result,  not  only  is  the  requesting  activity  blocked  when  it  is 
enqueued,  it  is  not  even  considered  by  the  scheduler  again  until  it  has  been  removed  from  the  queue.  In 
effect,  all  of  the  activities  that  preceded  it  in  the  queue  were  given  precedence  over  it,  regardless  of  the 
relative  urgency  of  their  time  constraints  or  any  other  dependency  considerations. 

It  would  be  much  more  appealing  to  apply  the  same  type  of  algorithm  to  select  which  activity  in  the 
queue  should  be  receive  access  to  the  resource  next  that  is  used  in  selecting  which  activity  should  execute 
next  in  general.  The  work  done  here  does  employ  such  an  integrated  approach  to  scheduling,  and  the 
interfaces  described  in  the  model  reinforce  this  integrated  scheduling  notion. 
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Chapter  3 

The  DASA  Algorithm 


The  primary  algorithm  investigated  in  this  thesis  is  called  the  DASA  (Dependent  Activity  Scheduling 
Algorithm)  algorithm.  It  addresses  the  dependency  concerns  descnbed  in  the  pre  jus  chapters  in  a  clear 
and  natural  manner.  The  algorithm  is  based  on  a  set  of  heurisocs  that  deliver  the  type  of  behavior  required 
in  real-time  systems. 

This  chapter  presents  the  DASA  algorithm.  First,  the  algorithm  is  described  in  general  terms,  placing 
emphasis  on  the  rationale  for  the  algorithm.  Then  a  formal  defininon  is  discussed,  providing  a  framework 
for  careful  analysis  of  the  algorithm.  Finally,  the  scheduling  example  from  Section  1.3  is  revisited.  This 
time  the  DASA  algorithm  is  employed  to  make  all  of  the  scheduling  decisions  to  contrast  its  behavior  with 
that  of  tiie  algorithms  previously  used. 

3.1.  Dependent  Activity  Scheduling  Algorithm 

In  this  section,  the  underlying  heuristics  for  the  DASA  algorithm  will  be  described,  along  with  the 
rationale  for  their  adoption.  This  should  help  to  explain  the  high  level  goals  for  the  algorithm.  That 
discussion  will  be  followed  by  an  informal  definition  of  the  DASA  algonthm.  (The  next  section.  Section 

3.2,  will  provide  the  formal  definition.) 

3.1.1.  Rationale  for  Heuristics 

The  DASA  algorithm  was  constructed  to  possess  a  set  of  properties,  each  of  which  is  logical  and  has 
appeal  on  its  own  merits.  Taken  together,  they  suggest  that  the  algonthm  will  be  quite  effective  in  handling 
scheduling  problems  with  dependency  considerations. 

Before  looking  at  the  definition  of  the  DASA  algonthm,  two  important  metrics  must  be  understood. 
These  are  the  notions  of  value  density  [Locke  86]  and  potential  value  density  Value  density  is  a  measure 
of  how  much  value  (as  defined  by  the  application)  per  unit  t  .ie  will  be  acquired  by  executing  a  phase.  In 
the  cases  considered  by  this  thesis,  where  ume-value  functions  are  simply  step  funcuoas,  the  value  density 
is  the  size  of  the  step  function  —  the  value  —  by  the  required  computauon  time |Q. 


19ln  more  complex  cases,  more  involved  Ume-value  functions  and  less  certain  computation  time  requirements  are  considered. 
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Potential  value  density  extends  the  notion  of  value  density  to  a  collection  of  phases  composed  of  a 
designated  phase  and  a  set  of  phases  on  which  it  depends.  In  fact,  the  potential  value  density  of  such  a 
coLlecuon  of  phases  is  the  total  of  their  individual  values  divided  by  the  total  required  computation  time  for 
all  of  the  phases  in  the  collection.  Furthermore,  since  phases  may  be  aborted  at  any  time,  aborting  phases 
must  be  handled  differently  than  those  that  are  executing  normally  —  an  aborting  phase  contributes  no 
value,  but  it  does  require  computation  time.  Therefore,  aborting  a  computation  will  always  act  to  reduce 
the  potential  value  density  of  a  collection  of  phases.  The  advantage  that  aborts  offer  is  that  they  may 
greatly  reduce  the  delay  that  must  be  incurred  before  starting  the  execution  of  a  designated  computation. 

With  these  metrics  in  mind,  the  properties  desired  for  the  DASA  algorithm  can  be  reviewed: 

1.  explicitly  account  for  dependencies  —  account  (in  terms  of  both  time  required  and  in 
potennal  value  available)  for  not  only  a  phase,  but  also  for  other  phases  on  which  it  depends; 

2.  minimize  effort  —  apply  the  minimum  amount  of  effort  necessary  to  allow  a  phase  to  be 
scheduled  (use  aborts  to  expedite  this  process); 

3.  maximize  retum/benefit  —  examine  phases  in  order  of  decreasing  potential  value  density, 
thereby  always  obtaining  the  greatest  return  (in  value)  on  a  given  investment  (of  time); 

4.  maximize  the  chance  of  meeting  deadlines  —  approximate  a  deadline  scheduler  insofar  as 
possible; 

5.  globally  optimize  schedule  —  review  the  schedule  constructed  incrementally  and 
collapse/remove  redundant  or  unnecessary  steps. 

3.1.2.  The  DASA  Algorithm 

Since  mutual  dependencies  among  activities  may  arise  during  the  course  of  execution,  the  DASA 
algorithm  actually  has  two  major  parts:  the  Dependency  Scheduling  Algorithm,  which,  given  a  set  of 
phases  (and  their  scheduling  parameters)  without  circular  dependencies,  will  select  the  next  phase  to  be  run, 
and  the  Deadlock  Resolution  Algorithm,  which  performs  a  similar  function  when  there  are  circular 
dependencies. 

The  following  two  sections  describe  each  of  these  component  algorithms  in  detail. 

3.1.3.  The  DASA  Algorithm:  Dependency  Scheduling 

The  DASA  algorithm  conforms  to  the  computational  model  defined  in  Chapter  2  and  meets  the  problem 
requirements,  while  also  possessing  the  properties  listed  in  Section  3.1.1  above. 

The  following  fragment  illustrates  how  the  potential  value  density  (PVD)  for  a  phase  p  is  calculated  for 
use  in  DASA: 
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PVD[p)  = 

0, 

Val(p)+PV{Dep(p)) 

ifpis  aborting 

otherwise 

ExecClocldp)+PT{Dep(p))' 

PV(p)  = 

0, 

0. 

Val(p)+PV{Dep{p)), 

ifp=nullphase 

if  quicker  to  abort  p  than  to  complete  p 
otherwise 

PTlp)  = 

0. 

<time  to  abort  p>, 

■crime  to  complete  p>-*-PT(Dep{p)), 

\ip~nullphase 

if  quicker  to  abort  p  than  to  complete  p 
otherwise 

Dep{p)  ~ 

nullphase , 

< phase  on  which  p  depends>. 

ifpis  ready  to  run 
otherwise 

Notice  that  this  calculation  demonstrates  a  property  mentioned  earlier:  the  least  amount  of  time  possible 
is  expended  to  make  the  phase  ready  to  run.  That  is  why  the  decision  is  made  to  abort  if  that  will  result  in  a 
shorter  delay  before  the  phase  in  question  is  ready  to  execute. 

For  any  phase,  the  set  of  phases  on  which  it  depends,  either  directly  or  indirectly,  and  which  must 
therefore  be  completed  or  aborted  before  it  can  run  is  called  its  dependency  list.  In  the  definition  for  PVD, 
the  set  of  phases  examined  while  evaluating  Depip)  constitutes  the  dependency  list  for  a  phase.  The 
general  concept  of  a  dependency  list  could  also  be  used  by  other  algorithms  similar  to  DASA,  although 
their  specific  definition  of  the  dependency  list  might  vary  somewhat  to  reflect  a  different  set  of  desired 
properties. 

A  simplified  procedural  version  of  the  DASA  Dependency  Scheduling  Algorithm  is  shown  in  Figure  3-1. 


1.  create  an  empty  schedule 

2.  determine  dependency  list  and  PVD  for  each  phase 

3.  if  deadlock  is  detected,  use  DASA  Deadlock  Resolution  Algorithm 

4.  sort  phases  according  to  PVD 

5.  examine  each  phase  in  turn  (highest  PVD  first) 

a  tentatively  add  phase  and  dependencies  to  schedule 

b.  test  feasibility  of  schedule 

c.  if  feasible,  make  tentative  changes;  else,  discard  them 

d.  reduce  schedule,  if  possible 


Figure  3-1:  Simplified  Procedural  Definition  of  DASA  Scheduling  Algorithm 

Notice  that  this  scheduling  algorithm  considers  all  of  the  existing  phases  each  time  a  scheduling  decision 
is  made.  Most  scheduling  algorithms  do  not  do  this  —  they  typically  consider  only  those  that  are  ready  to 
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run  immediately,  not  phases  that  are  blocked  awaiting  access  to  shared  resources.  A  cnuca!  objective  of 
the  DASA  algorithm  is  to  take  advantage  of  this  additional  informauon  to  improve  the  quality  of 
scheduling  decisions.  It  is  information  that  the  system  could  always  examine,  but  in  non-real-time  systems, 
there  is  no  motivation  to  look  at  it. 

3.1.4.  The  DASA  Algorithm:  Deadlock  Resolution 

The  work  that  has  been  done  up  to  this  point  focuses  on  the  Dependency  Scheduling  Algorithm  portion  of 
the  problem.  The  Deadlock  Resolution  Algorithm  must  still  be  devised,  although  it  can  be  anticipated  that 
it  will  have  properties  and  use  methods  that  are  similar  to  those  employed  by  the  Dependency  Scheduling 
Algorithm. 

3.2.  Formal  Definition  of  DASA 

Thus  far,  the  rationale  and  informal  description  of  the  DASA  algorithm  have  been  presented.  In  order  to 
provide  a  rigorous  specification  that  will  permit  analytic  study  of  the  algorithm,  a  more  formal  definition  is 
required.  That  definition  is  presented  in  the  following  section  along  with  explanations  of  interesting  and 
important  points. 

3 .2.1.  The  Formal  Definition 

The  formal  definition  is  cast  in  terms  of  the  automaton  model  presented  in  Chapter  2.  Remember  that  a 
scheduling  automaton  examines  histones  of  scheduling  events  and  either  accepts  or  rejects  them.  A  history 
is  accepted  by  a  scheduling  automaton  if  and  only  if  the  sequence  of  events  comprising  the  history  could 
have  been  generated  by  the  scheduling  algorithm  embedded  within  the  automaton. 

Although  all  scheduling  automata  share  a  common  framework,  each  individual  automaton  has  several 
unique  parts:  (1)  its  state  components;  (2)  the  scheduling  events  that  it  recognizes  —  including  the 
preconditions  and  postconditions  associated  with  recognizing  each  event  and  the  changes  that  occur  in  state 
component  values  as  a  result;  and,  of  course,  (3)  the  scheduling  algorithm  that  is  embedded  within  the 
automaton.  Each  of  these  parts  is  formally  defined  in  the  sections  that  follow  for  the  DASA  Scheduling 
Automaton. 

3.2.1. 1.  dasa  Automaton  State  Components 

The  DASA  algorithm  considers  all  existing  phases  each  time  a  scheduling  decision  is  made  In  the 
formal  definition  that  follows,  let  the  set  of  phases  currently  known  to  the  automaton  be  represented  as  {p0, 
P,.P2-  •  ■  •  I- 

Similarly,  let  the  set  of  resources  currently  known  to  the  automaton  be  represented  as  (r3,  rt.  r,.  .  |. 

The  state  components  associated  with  the  dasa  scheduling  automaton  are  presented  in  Figure  3-2. 
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General  State  Components: 

•  ExecMode:  PHASE— ) MODE  (MODE  is  either  normal'  or  'abort') 

•  ExecClock:  PHASE  ->  VIRTUAL-TIME 

•  AbortClock:  PHASE— ♦VIRTUAL- TIME 

•  ResumeTime:  PHASE  — ) TIMESTAMP 

•  Value:  PHASE  -> (TIMESTAMP ->  VALUE) 

•  Total:  VALUE  (initially  ’O') 

•  RunningPhase:  PHASE  (initially  'nullphase') 

•  PhaseElect:  MODE  x  PHASE  (initially  '<normal,  nullphase>') 

•  PhaseList:  list  of  PHASE  (initially  'i>’) 

Algorithm-Specific  State  Components: 

•  Owner:  RESOURCE—)  PHASE  (initially  'nullphase’  for  each  resource) 

•  ResourcesHeld:  PHASE  — >  list  of  RESOURCE 

•  ResourceRequested:  PHASE— )  RESOURCE  (initially  'nulLresource';  also  note: 

ResourceRequested(nullphase)  =  'nullresource') 

Domains  for  Value  Types: 

•  MODE:  normal  v  abort 

•  PHASE:  6  (p0,p7.p,.  ...  1  v  nullphase 

•  RESOURCE:  e  (r0*  ri'  r2<  ■  ■  ■  f  v  nullresource 

•  TIMESTAMP,  time,  expressed  in  ticks  of  standard  clock 

•  VALUE  real  number  >  0 

•  VIRTUAL^  TIME:  real  number  >  0  (represents  a  time  duration) 


Figure  3-2:  State  Components  of  DASA  Scheduling  Automaton 

There  are  two  distinct  groups  of  state  components  shown:  general  state  components,  which  arc  found  in 
any  scheduling  automaton,  and  algorithm-specific  state  components,  which  arc  defined  only  for  a  particular 
scheduling  automaton. 

The  general  state  components  were  discussed  in  Chapter  2.  They  include  a  number  of  components  that 
describe  important  cbaractensbcs  of  each  individual  phase  (ExecMode.  EixecClock,  AbortClock, 
ResumeTime,  and  Value),  as  well  as  components  that  indicate  the  status  of  the  automaton  itself  (Total, 
RunningPhase,  PhaseElect,  and  PhaseList). 


All  of  the  algorithm-specific  state  components  of  the  DASA  Scheduling  Automaton  deal  with  requesting 
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and  holding  shared  resources.  The  relation  Owner  indicates  which,  if  any.  phase  currently  possesses  each 
of  the  shared  resources.  The  Owner  of  all  unassigned  resources  is  nullphase.  The  ResourcesHeld  relation 
associates  with  each  phase  the  list  of  resources  that  have  been  granted  to  that  phase.  And  finally,  the 
ResourceRequested  relation  specifies  which  resource  a  given  phase  desires.  Whenever,  there  is  no 
unsatisfied  resource  request  for  a  phase,  the  corresponding  ResourceRequested  value  is  nullresource. 

The  bottom  portion  of  Figure  3-2  defines  the  values  that  each  of  the  state  components  may  assume.  All 
of  these  are  general  value  domains  that  were  discussed  when  the  scheduling  automaton  model  was 
presented  in  Chapter  2.  They  are  repeated  here  only  for  convenience  —  they  allow  the  relation  definitions 
to  appear  in  context  so  that  eariier  material  need  not  be  consulted. 

An  initial  value  is  shown  for  many  of  the  state  components.  These  values  indicate  that,  at  the  outset, 
there  are  no  phases  known  to  the  automaton,  no  value  has  been  accrued,  all  of  the  shared  resources  are 
available,  and  the  processor  is  idle.  Each  of  the  relations  that  provide  information  for  each  phase  in  the 
system  is  initially  empty  since  there  are  no  phases.  As  phases  arrive  (indicated  by  issuing  request-phase 
events),  entries  are  made  in  each  of  these  relations. 

Definitions,  or  anywhere  else] 

Each  activity /phase  has  a  state  associated  with  it.  It  is  either  running  or  it  is  blocked.  If  it  is  blocked,  it 
may  have  been  preempted  or  it  may  have  blocked  to  wait  on  a  resource  that  was  unavailable  when 
requested. 

Runningip)  a  p^RunningPhase 
Blocked(p)  =  p*  RunmngPhase 

ResourceWaitingip )  =  (Eir)(ResourceRequested(p)^r/\r*nullresource/\Owner{r)  *  p) 

Preempted(p)  =  Blocked{p)/\-^ResourceWaiting{p) 

Access  Queues  for  Resources.  There  is  one  state  component  that  is  not  present  in  the  DASA  Scheduling 
Automaton  but  is  commonly  found  in  other  scheduling  automata  for  this  problem  domain:  a  relation  that, 
given  a  resource,  specifies  the  queue  of  phases  that  are  waiting  for  access  to  the  resource.  That  state 
component  is  not  found  in  this  automaton  because  it  tends  to  reflea  an  ordering  among  pending  requests 
for  a  shared  resource  —  for  example,  requesters  may  be  served  in  a  FIFO  fashion  or  according  to  their 
priority.  While  the  DASA  algorithm  will  in  some  sense  order  such  requests,  it  is  done  in  a  completely 
dynamic  fashion.  The  needs  of  each  phase,  including  access  to  shared  resources,  are  coasidercd  along  with 
the  benefit  of  executing  the  phase  each  time  a  scheduling  decision  is  made. 

32. 1.2.  Operations  Accepted  by  dasa  Automaton 

The  operations  recognized  by  the  DASA  scheduling  automaton  and  their  preconditions  and 
postconditions  are  shown  in  Figures  3-3,  3-4,  and  3-5.  Figure  3-3  presents  the  'request-phase'  operation, 
which  is  used  to  initiate  each  computational  phase  of  the  activities  comprising  the  application.  Figure  3-4 
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depicts  the  other  operations  involving  phases  that  are  recognized  by  the  DASA  Scheduling  Automaton. 
And  Figure  3-5  shows  those  operations  that  deal  specifically  with  shared  resources.  The  following 
paragraphs  describe  each  of  these  operations  in  detail. 


*  ^ event  request-phase(v.texptcttd)p 
preconditions: 

true  <No  preconditions  here  so  that  interrupts  and  other  new  phases 
can  occur  at  any  ume> 

postconditions: 

if  (RunningPhase  =  p)  then 

if  (ExecMode(p)  =  normal)  then 

Total’  =  Total  +  Value(p)(tevem) 

else 

;no  value  for  aborted  phase 
; release  the  resources  acquired  during  the  phase 
for  r  in  ResourcesHeldip) 

Owner' (r)=t> 

ResourcesHeld  (p)-0 
Value '(p)  =  v 
ExecClock'(p)  =  texpecIed 
AbortGock’(p)  =  0 
ExecMode'(p)  =  normal 
mote  that  p  is  not  res  ounce -waiting 

tmake  sure  p  is  part  of  the  list  of  phases,  if  necessary 
lf  (‘exited  >  0)  ihen 

PhascList'  =  PhaseList  ^  {pi 

else 

PhaseList'  =  PhaseList  -{pi 
Phase  Elect'  =SelectPhase(PhaseLisf^°) 
if  (p  =  RunningPhase)  then 

.give  up  processor  until  next  'resume-phase' 
RunningPhase  =  nullphase 

else 

: happened  under  interrupt — leave  ’RunningPhase'  alone 


Figure  3-3:  ’RequestPhase’  Operation  Accepted  by  DASA  Scheduling  Automaton 
Request-Phase  The  ’request-phase’  operation  delimits  computational  phases  for  an  activity.  Each 


J0Herc,  the  value  xssigned  to  one  stxte  component  (PhastLisO  tn  these  postconditions  is  used  to  determine  the  value  of  another 
slate  component  (PhascElecf )  tn  the  same  group  of  postconditions.  Ln  the  interests  of  convenience  and  clenty,  this  hts  been  done, 
nther  than  writing  alJ  of  the  new  suite  component  vsJues  m  terms  of  only  the  old  suite  component  values  Of  course,  it  is  possible  io 
express  the  new  vslue  of  PhaseElecl  in  terms  of  the  old  state  component  values,  as  follows: 

*/<  >  °> ,htn 

PhaseElecl'  *  SelectPhaseiPhaseList  u  {p}) 


PhaseElecl'  -SelectPhaseiPhaseList  -  \p)) 
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•  t  nl  abort -phase! pi  0: 

preconditions: 

(Running  P  as  e-=nullphase)/\(Phase(PhaseElect)=p) 

/ \(Mode(PhaseElect)=abort ) 

postconditions: 

ExecMode’(p)  =  abort 
ResumeTune'(p)  =  tevenI 

ResourceRequested (p)= 0  ; cancel  attempt  to  acquire  more  resources 

RunningPhase'=Phase(PhaseElect) 

•  teVtntPreemP,-Phase<P)  S 

preconditions: 

( RunmngPhase=p)/\(RunningPhase  *  nullphase) 

/\(RunningPhase*  Phase(PhaseElect)) 

postconditions: 

if  (ExecMode(p)  =  normal)  then 

ExecClock’(p)  =  ExecClockfp)  -  (t  -  ResumeTime(p)) 

else 

AbortClock’(p)  =  AbonClock(p)  -  (t  -  ResumeTime(p)) 

tnote  p  is  not  resource-waiung 
RunntngPhase'=nullphase 

•  Wni  tesume-phase(p)  S: 

preconditions: 

(RunmngPhase=nullphase)/\(Phase(PhaseE!eci)=p) 

o.(Phase(PhaseElect)  *  nullphase)MMode{PhaseElect)-normaF) 
f\-^ResourceWaiting(Phase(PhaseElect)) 

postconditions: 

ResumeTime’(p)  =  tevent 
RunningPhase'=Phase(PhaseElect) 


Figure  3-4:  Other  Phase  Operations  Accepted  by  DAS  A  Scheduling  Automaton 
activity  begins  with  a  ’request-phase’  operation  that  declares  its  needs  for  its  initial  computauonal  phase. 
Subsequent  ’request-phase’  events  mark  the  end  of  one  computational  phase  and  the  beginning  of  another. 
A  final  ’request-phase'  operation  denotes  the  completion  of  the  activity's  last  computational  phase.  Of 
course,  simple  activities  may  consist  of  only  one  or  possibly  a  few  computational  phases. 

The  precondition  for  accepting  a  ’request-phase’  operation  is  simply  true.  That  is,  a  'request-phase' 
operation  can  be  accepted  at  any  time  under  any  circumstances.  This  arrangement  allows  new  phases  to 
arrive  at  any  instant,  thus  permitting  activities  to  be  submitted  to  the  automaton  asynchronously,  just  as 
they  would  be  if  they  were  initiated  in  response  to  interrupts. 

The  two  arguments  associated  with  each  ’request-phase'  event  serve  to  specify  the  anucipated  needs  of 
the  new  computational  phase:  (1)  v,  die  time-value  function  defining  the  value  to  the  application  of 
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request  r)  p: 
preconditioas: 

(RunningP  hase=p)/\(RunningP  hase  *  nullpkase) 

postconditions: 

ExecClock’(p)  =  ExecClock(p)  -  (tevem  -  ResumeTime(p)) 

ResourceRequested (p)=r  ; indicate  p  is  resource-waiting 

PhaseElect'=SelectPhase(PhaseList) 

RunningP  hase=nullphase  :give  up  processor  until  ’ grant' ed  resource 

•  fWJI|  granl(p,  r,  undotime(r))  S: 
preconditions: 

(RunningPhase=nullphase)MPhase(PhaseElect)=p)/\(r*nullresource) 

/ \(ResourceRequested(Phase(PhaseElect))=r ) 

/\(Mode(PhaseElect)=normat) 

postconditions: 

ResumeTime’(p)  =  tevem 

AbortGock’(p)  =  AbonQock(p)  +  undodme(r) 

RunningP  hase'  -Phase(P  hase  Elect) 

Owner\r)=p  ; indicate  'p'  is  owner  of  resource 

ResourceRequested  (p)=6 
ResourcesHeld  {p)=ResoucesHeldr 


Figure  3-5:  Resource  Operations  Accepted  by  DASA  Scheduling  Automaton 
completing  the  phase  at  any  instant  in  time;  and  (2)  ftxpec,rd,  the  amount  of  computation  time  that  would  be 
expected  to  execute  the  phase  if  there  were  no  contention  for  shared  resources  —  including  the  processor. 

In  addition,  there  is  no  indication  about  the  shared  resources  that  will  be  needed  by  the  phase.  This 
reflects  the  belief,  explained  earlier,  that  in  order  to  allow  a  potentially  high  degree  of  concurrency,  it  may 
often  be  necessary  to  use  techniques  that  preclude  the  exact  knowledge  of  which  resources  will  be  needed 
by  a  computational  phase. 

The  ’request-phase'  operation  has  the  longest  set  of  postconditions  of  any  of  the  operations  accepted  by 
the  DASA  Scheduling  Automaton.  This  is  due  in  large  part  to  the  fact  that  the  postconditions  handle  the 
conclusion  of  one  computational  phase  and  the  initiation  of  another.  If  the  currently  executing  phase  issues 
the  ’request-nhase’  operation,  then  the  operation  marks  a  transition  between  phases,  In  that  case,  the  value 
accrued  by  completing  the  phase  is  added  to  the  running  total  for  the  application,  and  any  shared  resources 
held  by  the  activity  are  released.  (Note  that  if  the  activity  had  been  aborting  the  computational  phase,  no 
value  would  be  gained  by  completing  the  phase,  since  that  simply  represents  the  completion  of  the  abort.) 

If  the  activity  that  issued  the  ’request-phase’  operation  was  not  executing  at  that  time,  then  it  is  a  new 
activity.  There  is  no  previous  phase  to  handle  in  that  case. 


Whether  or  not  the  computational  phase  is  the  first  for  the  activity,  the  ’request-phase’  postconditions 
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dictate  that  the  time-value  function  and  expected  compute  time  parameter  are  associated  with  the  new 
phase.  The  expected  compute  time  parameter  is  used  to  initialize  a  virtual  clock,  called  ExecClock.  This 
clock  indicates  the  amount  of  time  required  to  complete  the  current  phase  for  a  given  activity. 

Other  state  components  are  altered  as  well.  AbortClock  is  similar  to  ExecClock  —  it  indicates  the  amount 
of  time  required  to  abort  the  current  phase  of  an  activity.  Each  time  a  new  shared  resource  is  acquired 
during  a  phase.  AbortClock  is  increased  by  a  resource -specific  amount  of  time.  Initially,  it  takes  no  time  to 
abort  a  computational  phase  since  nothing  has  been  done  yet  and  no  shared  resources  have  been  acquired. 
Furthermore.  ExecMode  for  the  new  phase  is  ' normal" .  not  'abort'. 

It  is  possible  that  the  'request-phase’  event  may  signal  the  completion  of  the  final  phase  of  an  activity.  In 
that  case,  the  required  computation  time,  texpecte(p >s  declared  to  be  zero  —  that  is.  no  more  computational 
cycles  are  needed  for  the  activity. 

If  the  'request-phase'  event  does  mark  the  completion  of  processing  for  an  activity,  then  the  phase  is 
removed  from  the  list  of  known  phases.  PhaseList.  Otherwise,  the  phase  is  a  member  of  PhaseList. 

Finally,  SelectPhaseQ  is  consulted  to  decide  which  phase  should  be  executed  now.  Furthermore,  if  the 
currently  executing  activity  (RunnmgPhase)  issued  the  'request-phase'  event,  it  surrenders  the  processor  — 
clearing  the  way  to  execute  the  PhaseElect  specified  by  S elect Phase().  (Note  that  this  really  has  no  effect 
if  PhaseElect  is  pan  of  the  currently  executing  activity.  In  that  case,  wluie  the  processor  will  nominally 
begin  executing  the  nullphase.  it  will  actually  resume  execution  of  the  PhaseElect  immediately.  The 
transition  to  the  nullphase  is  only  a  convenience  in  terms  of  modeling  the  automaton.  After  reviewing  the 
other  scheduling  events  accepted  by  the  DASA  Scheduling  Automaton,  the  convention  employed 
throughout  to  mark  potential  changes  in  execution  due  to  a  preemption,  abortion,  or  unsatisfiable  request 
should  be  dear.) 

Abort-Phase.  As  modeled,  phases  are  aborted  only  as  a  result  of  a  decision  by  the  scheduling  function, 
SelectPhaseQ 21. 

By  convention,  each  time  the  executing  activity,  RunningPhase.  makes  a  new  request  to  either  begin  a 
new  phase  or  to  acquire  a  new  shared  resource  —  necessitating  a  scheduling  decision  —  the  activity  gives 
up  the  processor.  That  is.  as  a  postcondition  for  accepting  one  of  these  requests,  RunningPhase  is  set  to  be 
nullphase.  This  is  done  to  meet  the  preconditions  to  accept  either  an  'abort-phase'  or  a  'resumc-phase’ 
event.  Once  the  processor  is  idle,  then  if  the  execution  mode  of  PhaseElect  is  'abort',  then  an  abort-phase’ 
event  can  be  accepted  by  the  DASA  Scheduling  Automaton. 

The  postconditions  for  this  event  make  sure  that  the  phase  is  aborting,  note  the  time  at  which  execution 


■'This  should  not  be  viewed  ii  precluding  the  possibility  of  »n  iciivity  aborting  a  phase  autonomously  —  perhaps  due  to  a  failure 
within  a  transaction.  Rather,  the  model  can  easily  be  extended  to  accommodate  mat  possibility:  If  the  executing  activity  decides  to 
abort  the  current  phase,  it  issues  an  'abort-self  event.  This  event  changes  the  execution  mode  of  the  phase  to  'abort',  consults 
SelectPhaseQ  to  determine  what  to  run  next,  and  gives  up  the  processor  When  the  scheduler  selected  that  phase  to  begin  its  abort 
processing,  it  would  issue  an  abort  phase'  event,  and  processing  would  continue  as  described  above. 
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resumed,  cancel  any  outstanding  requests  for  shared  resources  (since  no  new  resources  must  be  acquired  to 
undo  whatever  was  done  to  those  previously  acquired),  and  designate  the  new  executing  phase. 

Preempt-Phase.  As  indicated  by  us  precondition,  the  scheduler  issues  a  'preempt-phase'  event  if  the 
processor  is  executing  some  phase  other  than  the  PhaseElect  or  the  nullphase.  In  response,  the  current 
RunnintPhase  is  suspended,  its  execution  clock  (either  ExecClock  or  AbortClock ,  depending  on  the 
execution  mode  )  is  updated  to  reflect  the  true  time  left  to  free  the  shared  resources  held  by  the  phase,  and 
the  processor  is  left  idle 

Of  course,  the  processor  will  probably  not  remain  idle  for  long  since  either  an  'abort -phase',  a  'resume- 
phase'.  or  a  grant'  event  will  be  issued  to  execute  another  phase:  (1)  an  'abort-phase'  event  is  issued  for  a 
phase  that  is  being  aborted,  (2)  a  'resume -phase'  event  is  issued  for  a  phase  that  is  executing  normally,  but 
is  not  waiting  for  a  resource  (that  is.  it  is  a  previously  preempted  phase);  and  (3)  a  'grant'  event  is  issued 
for  a  phase  that  is  executing  normally  and  is  waiting  for  access  to  a  shared  resource.  All  three  of  these 
scheduling  events  require  that  the  processor  be  idle  before  they  dispatch  the  next  phase.  (Along  with  the 
'preempt-phase'  event,  the  'request-phase'  and  'request'  events  also  leave  the  processor  idle  when 
appropriate  to  set  the  stage  for  these  phase-dispatching  events.) 

Resume- Phase.  The  'resume-phase'  event  resumes  the  execution  of  a  previously  preempted  phase.  The 
processor  must  be  idle  before  a  'resume-phase'  event  can  be  accepted  by  the  DAS  A  Scheduling 
Automaton,  and  the  phase  resumed  must  be  executing  normally  —  as  opposed  to  aborting  —  and  must  not 
be  waiting  on  access  to  a  shared  resource. 

The  postconditions  for  the  acceptance  of  a  'resume-phase'  event  note  the  time  at  which  execution  of  the 
phase  resumed  and  assign  the  processor  to  execute  the  phase. 

Request-  A  'request'  event  signals  that  the  currently  executing  phase  wishes  to  access  a  shared  resource. 
As  denoted  by  the  event’s  preconditions,  such  a  request  can  be  made  at  any  time  while  the  phase  is 
executing  on  the  processor. 

After  accepting  a  ’request'  event,  the  postconditions  for  the  event  update  the  requesting  phase's  execution 
clock  to  indicate  the  exact  time  left  to  complete  the  phase,  record  the  resource  that  has  been  requested  by 
the  phase,  select  the  next  phase  to  be  executed  (possibly  the  requesting  phase),  and  remove  the  requesting 
phase  from  the  processor. 

It  should  be  understood  that  the  decision  to  suspend  the  requesting  phase’s  execution  is  only  made  to 
provide  a  simple,  coherent  formal  model,  not  to  suggest  the  actual  design  of  an  implementation  of  the 
DASA  algorithm.  Notice,  for  example,  that  in  the  formal  model,  it  is  quite  possible  that  a  phase  could 
request  a  resource  that  is  currently  available,  give  up  the  processor,  and  immediately  be  reassigned  the 
processor  as  the  result  of  a  'grant'  event.  This  is  perfectly  fine  in  the  model,  but  an  efficient 
implementauon  of  the  algorithm  should  decide  whether  the  processor  should  actually  be  turned  over  to 
another  phase  before  ever  suspending  exccuuon  of  the  errent  phase. 
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Grant  The  'grant'  scheduling  event  assigns  the  processor,  which  must  be  idle,  to  execute  a  phase  that 
has  been  blocked  awaiting  access  to  a  shared  resource.  The  phase  assigned  to  execute  has  been  previously 
selected  and  is  designated  Phase  Elect. 

Once  the  'grant'  event  has  been  accepted  by  the  DASA  Scheduling  Automaton,  the  postconditions 
associated  with  that  event  record  the  time  at  which  the  phase  is  granted  the  resource,  adjusts  the  AbortClock 
to  indicate  the  increment  in  work  that  is  required  to  undo  actions  on  the  newly  acquired  shared  resource, 
manipulates  various  relations  to  show  that  the  resource  now  belongs  to  the  designated  phase,  and  starts  the 
processor  executing  that  phase. 

Although  there  are  'request'  and  ’grant’  events,  there  is  no  explicit  ‘release’  event.  This  is  due  to  the 
model  of  computation  that  has  been  adopted.  Since  all  activities  are  composed  of  a  sequence  of 
computational  phases  and  all  shared  resources  that  are  acquired  during  a  phase  are  released  at  the 
completion  of  the  phase,  there  is  no  need  for  such  an  event.  Rather,  an  implicit  release  of  these  resources  is 
performed  as  part  of  the  'request- phase'  event,  which,  among  other  things,  denotes  the  completion  of  a 
phase  (as  descnbed  above). 

3.2. 1.3.  ’SelectPhase’  Function  for  DASA  Automaton 

The  function  'SelectPhaseO'  embodies  the  DASA  scheduling  algorithm.  As  shown  in  Section  3. 2. 1.2, 
SelectPhaseQ  is  evaluated  each  time  a  'request-phase'  or  a  'request'  event  is  encountered.  In  Figure  3-6, 
SelectPhaseO  is  formally  defined  as  a  mathematical  function.  Since  this  definition  looks  quite  different 
than  the  brief  procedural  definition  offered  in  Section  3.1.3,  a  few  comments  are  in  order  to  explain  the 
utility  of  this  format  and  us  organization. 

The  algorithm  is  desribed  as  a  mathematical  function  for  a  few  reasons.  Fust  and  foremost,  it  is  a  concise 
and  precise  notation.  But  it  also  is  more  expressive  in  some  ways  than  procedural  definitions.  Specifically, 
thi:  mathematical  format  is  capable  of  expressing  the  sequencial  nature  of  a  set  of  operations  —  by  using 
functional  composition,  for  example,  where  each  function  corresponds  to  one  of  the  sequential  operations. 
At  the  same  lime,  this  mathematical  format  can  also  express  the  nondeterminism  that  is  present  in  the 
algorithm  definition.  For  instance,  the  order  in  which  the  elements  in  a  list  are  examined  may  or  may  not 
be  important.  When  the  order  is  important,  there  is  a  specific  method  to  describe  the  order.  This  is  said  to 
be  deterministic,  in  that  there  is  only  one  correct  order.  When  the  order  is  unimportant,  any  order  will  do; 
and  so  this  case  is  said  to  be  nondeterministic.  A  typical  procedural  definition  cannot  readily  capture  this 
nondeterminism.  Such  a  definition  would  usually  have  to  specify  some  ordering,  even  if  the  ordering  was 
not  critical. 

The  function  'SelectPhaseO',  when  given  a  list  of  phases,  selects  the  next  phase  to  run  and  specifies  its 
execution  mode  (either  'normal'  or  ’abort’).  Informally,  the  definition  shown  for  'SelectPhaseO'  in  Figure 
3-6  determines  a  set  of  phases  that  can  feasibly  meet  their  time  constraints  given  all  of  the  information  that 
is  currently  known  about  them.  It  then  selects  one  of  the  phases  from  this  set  that  must  be  done  by  the 
earliest  deadline  and  designates  it  as  the  next  phase  that  the  processor  should  execute. 
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All  of  d  :  phases  in  the  phase  list  P  that  was  passed  to  SelectPhase ()  are  considered  when  constructing  the 
list  of  phases  that  can  feasibly  execute.  Also,  as  each  phase  is  examined  in  turn,  any  dependency  that 
prevents  it  from  executing  immediately  are  noted  and  resolved  by  indicating  those  other  activiues  that  must 
precede  it  in  any  schedule  —  either  completing  or  aborting  their  current  phases. 

To  see  how  the  definition  actually  specifies  the  desired  behavior,  a  closer  look  is  necessary  Towards  that 
end,  consider  constructing  the  definition  from  the  bottom  up.  While  a  few  of  the  functions  appearing  in  the 
definition  have  already  been  discussed  bnefly,  others  are  totally  new 

The  following  descriptions  constitute  an  informal  definition  of  the  functions  comprising  SelectPhase <). 
Often  only  the  "main"  or  "normal"  case  value  will  be  discussed  for  a  function,  even  though  its  definition 
includes  a  number  of  other  cases  as  well".  Tins  is  because  the  other  cases  usually  handle  degenerate 
situations  that  arise  as  a  result  of  the  recursive  nature  of  some  of  the  function  defimuons. 

To  start,  remember  that  a  few  basic  functions  were  described  in  Section  2.3.1.  They  include  Deadline () 
and  V'a/()  and  are  used  in  the  definitions  that  follow  as  basic  building  blocks. 

Also  remember  that  SelectPhaseQ  is  a  function  that  is  evaluated  within  the  context  of  the  DASA 
scheduling  automaton.  As  such,  it  has  access  to  all  of  the  state  components  of  the  automaton,  which  in  turn 
provides  acces  to  all  of  the  status  information  for  each  phase  in  the  system  Furthermore,  since 
SelectPhaseQ  is  always  evaluated  as  a  result  of  accepung  a  scheduling  operanon,  the  i^.ent  that  appears  in 
the  formal  definition  refers  to  the  umestamp  for  the  a  ...  event. 

With  that  background  in  mind,  v  v  wan  begin  to  examine  the  forma)  defintion  of  SelectPhaseQ  in  earnest. 
Consider  first  the  set  of  functions  that  form  the  dependency  lists  and  evaluate  the  potential  value  densities 
of  all  of  the  phases  in  the  system. 

'.Tie  function  'DepfV,  evaluated  for  a  specified  phase,  returns  as  its  value  the  phase  that  is  currently 
preventing  the  specified  phase  from  executing  (due  to  a  dependency).  If  the  phase  is  ready  to  execute 
immediately,  then  the  'nullphase'  is  the  value  of  ’Dep()'.  Otherwise,  the  phase  has  requested  a  shared 
resource  and  is  dependent  on  the  owner  of  that  resource  —  that  is  the  phase  that  currently  holds  the  shared 
resource  —  if  there  is  one.  The  phase  holding  the  resource  must  relinquish  it  before  the  dependent  phase 
can  continue  execution. 

The  resource  can  be  relinquished  in  one  of  two  wavs  either  the  phase  can  complete  its  normal  course  of 
execution  or  it  can  be  aborted  Both  of  these  alternatives  take  ume~3,  and  the  DASA  algorithm  attempts  to 
minimize  the  amount  of  time  waiting  for  the  resource  So  DASA  completes  the  phase  unless  it  is  faster  to 

abort  \L 


Which  case  is  ig  be  used  to  evaluate  the  function  typically  depends  on  the  value  of  one  or  more  arguments  to  die  function 

was  pointed  out  earlier,  a  phase  that  has  hern  aborted  docs  no!  mstanUr.rous.v  return  the  shared  resources  allocated  to  it  to  the 
system  Rather,  the  shared  resources  must  be  placed  into  a  meamr.gtui.  a  ccpiahir.  sate,  and  « p.  ss:h|\)  cons.*. lent  state  prior  to  iheu 
release  It  is  the  processing  that  puts  the  shared  resources  into  these  acceptable  slates  that  consumes  lime  after  an  abort  has  been 
tasued  for  the  phase. 
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SelectPhase(P)  = 

pickone(mustfimshby(DLfirst(mpplist)J>sch'duieJ'P))), 

where 

mpplist  =tobescheduled(P  scheduIe/P)) 
pickone(MPP)  = 

<normaUp> ,  if  <normal,p>  e  MPP  cJdep{p)=nullphase 

<abort,p> ,  if  <abortp>  e  MPP 

A^(3q)(<normal,q>£  MPP 
cDep(q)=nullphase ) 

<normal,nullphase>,  otherwise 

DLfirsl(MPP)  = 

<*>,  ifMPP=6 

Deadlineip)  |  (<normalp>  €  MPP) 

/ \(yq){<normal.q>  e  MPP  — »  Deadline(q)>  Deadlineip)), 

otherwise 


P  scbeduleJ^P^ 

0, 


(p )  Ip  )  >• 


if/5^ 

'^e  PleastP\^P'> 


P feasible^  ~ 


t, 

P, 


P feasible  (P-{p ]).  where/? e  PleaslPV(P), 


i(P=C 

iifeasible(P) 

otherwise 


P least P\^p)  ~ 

t> ,  if  /*=<& 

{p  |(p€  P) 

A(Vq)(qe  P  -+((PVD(p)<PVD(q)) 
a (PVD(p)=PVD(q)  — >  ExecClock{p)  <  ExecClock{q))))% 

otherwise 


tobescheduled(P)  = 

<5.  if 

{ <normal,p> )  ^  dependencylistip)  vj  tobescheduled(P-(p  | ), 

ifpe  P 


dependenr.listfp)  = 

C>,  if  Dep{p)=nullphase 

dependency  list(Depip))  vj  [<normal,Dep(p)>\, 

\lAbortClock{Dep(p))  >  ExecClock(Dep{p)) 
{<abortJ)ep(p)>},  otherwise 


Figure  3-6:  Functional  Form  of  DASA  Algorithm 
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mustcompleteby(t.P)  = 

O’ 

[p  |  [<normal,p>€  tobescheduled{P)cDeadhneip)<t)}. 

otherwise 

mustfinishbyUJ *)  = 

6.  i{P=$v  t<t^enlv  mustcompletebyitJ*)^ 

reduce(t ,  /*,  {<normal,p>}cjdependencylisi(p)^jmusifinishby(:J3-{p})). 

if pe  mustcompleteby{tJ’) 


reduce(t.PMPP)  = 

reduce{tJ’MPP-[  <ubortp>\). 


if  <abortp>,<normalp>  e  MPP 
a <abort,p>£  mustfinishby{C  J3) 
otherwise 


feasible(P)  =  /rue, iff (V/)[(/>/  )-» timerequiredby(mustfinishby(tj’))  <  (t-t  W)J 


timerequiredby(MPP)  = 

6, 


0,  itMPP=6 

ExecClock(p)+timerequiredby(MPP-l  <normal,p>)), 

if  <normal,p>  e  M/V* 

AbortClock{p)+timerequiredby{\fPP-\  <abort,p>  j), 

if  <abortp>  6  M/>/3 


FVO(p)  =  0. 

Val{p)+PV(Dep{p)) 
ExecC  locldp)+P  r(Depip))' 


ifExecMode{p)=abon 

otherwise 


m.p)  =  o, 

o. 

Val(p)+PV(Depip)), 

PT(p >  =  0. 

AbortClockip), 

ExecClockip)+PT(Dep(p)), 

Depip )  =  nullphase, 

Ow  neriResour  ceRe  quest  ed(p)). 


if  p^nullphase 

i iAbortCInrldp'i  <  ExecClockip) 
otherwise 

if  p=nullphase 

U  AbortClockip)  <  ExecClockip) 
otherwise 

if  ResourceRequested(p)=nullresource 
otherwise 


Figure  3-6:  Functional  Form  of  DASA  Algorithm,  continued 
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The  function  'dependencylist()’  uses  the  information  supplied  by  'Dep()'  about  the  dependencies  of 
individual  phases  to  construct  a  list  that  includes  all  of  the  phases  that  must  execute  before  a  specified 
phase.  'DependencyhstO'  also  specifies  the  execution  mode  for  each  of  the  phases  that  must  be  executed 
prior  to  the  specified  phase.  Therefore,  the  dependency  list  is  actually  a  set  of  mode-phase  pairs  of  the 
form  <mode,phase>.  It  is  in  this  function  that  the  decision  to  minimize  the  length  of  time  to  remove 
dependencies  is  implemented. 

The  definition  of  the  function  is  recursive.  It  initially  examines  the  phase,  p,  that  was  given  as  its 
argument  If  p  is  not  dependent  on  any  other  phase,  then  its  dependency  list  is  empty.  Otherwise,  it  will  be 
non-empty.  Specifically,  if  it  is  faster  to  abort  the  phase  on  which  p  uepends.  then  the  dependency  list  will 
have  only  one  member  <abort,Dep(p)>.  Alternatively,  if  it  is  at  least  as  fast  to  complete  the  normal 
execution  of  the  phase  on  which  p  depends,  then  p's  dependency  list  will  be  constructed  by  adding 
<normalJDep{p)>  to  the  dependency  list  of  Depip). 

Once  a  dependency  list  has  been  determined  for  a  phase,  it  is  possible  to  evaluate  the  potential  value 
density  for  that  phase.  This  is  done  by  the  funcuon  PVDQ,  which  employs  two  auxiliary  funcuons,  PV{) 
and  PT().  These  functions  are  similar  to  those  discussed  earlier  in  this  chapter,  in  Section  3.13.  They  total 
the  value  that  may  be  accrued  and  the  execution  ume  that  is  required  jointly  by  the  given  phase  and  all  of 
the  phases  in  its  dependency  list.  (Note  that  aborting  a  phase  requires  time  but  yields  no  value  directly.) 
These  totals  are  then  used  to  determine  the  potential  value  density  for  the  specified  phase. 

The  function  P  leaslPVQ  examines  a  set  of  phases  and  returns  the  subset  of  phases  that  have  the  lowest 
potenual  value.  In  case  more  than  one  phase  has  the  same  (lowest)  potential  value  density,  the  phase  or 
phases  that  will  consume  the  least  execution  time  is  returned.  This  choice  is  made  because,  when 
considering  two  phases  with  the  same  PVD,  the  phase  that  executes  longer  will  obtain  a  higher  value  than 
the  one  that  runs  shorter  since  value  is  the  product  of  PVD  and  execution  time. 

.Another  group  of  functions  determine  the  amount  of  time  required  to  carry  out  a  specified  set  of 
executions  and  aborts  over  all  of  the  cnbcal  time  intervals,  thereby  allowing  the  feasibility  of  the  specified 
computations  to  be  ascertained.  So,  for  instance: 

•  timerequiredbyO  —  given  a  set  of  mode-phase  pairs,  this  function  determines  the  total 
execution  time  required  to  carry  out  all  of  the  specified  computations; 

•  mustcompletebyO  —  given  a  time  and  a  set  of  phases,  this  function  identifies  those  phases  that 
must  complete  execution  by  the  specified  time; 

•  mustfinishbyQ  —  given  a  time  and  a  set  of  phases,  this  function  identifies  all  of  the  normal 
executions  and  abortions  that  must  finish  by  the  specified  time,  whereas,  mustcompletebyO 
idenufied  those  phases  that  had  to  complete  their  normal  executions  by  the  specified  time. 
mustfinishbyQ  adds  to  that  group  all  of  the  other  wort;  that  must  be  done  in  order  to  remove 
any  existing  dependencies  that  might  prevent  those  phases  from  executing  immediately;  also 
notice  that  this  funcuon  uses  another  function,  reduce (),  to  eliminate  unnecessary  aborts  from 
the  resultant  list, 

•  reduce 0  —  this  funcuon  eliminates  unnecessary  abets  by  noticing  cases  where  the  same 
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phase  is  being  both  completed  and  aborted24,  but  the  completion  must  be  done  prior  to  the 
abort  due  to  the  dependencies  currently  in  effect;  of  course,  there  is  no  need  to  abort  a  phase 
once  it  has  completed, 

•  feasibleQ  —  given  a  set  of  phases,  this  function  determines  whether  all  of  the  phases  in  the  set, 
along  with  all  of  the  other  computations  on  which  they  depend,  can  meet  their  deadlines;  for  a 
schedule  to  be  feasible,  at  every  point  in  time  the  total  amount  of  time  required  to  complete  the 
computations  that  must  be  done  by  that  time  must  never  exceed  the  actual  time  remaining  until 
that  time. 

With  this  set  of  functions  to  use  as  building  blocks,  it  is  possible  to  desenbe  at  a  fairly  high  level  how1  to 
select  the  phase  that  should  execute  next. 

A  set  of  phases  that  can  be  feasibly  run  (given  current  knowledge  of  requirements  and  resources)  is 
constructed  by  examining  each  existing  phase  ordered  by  PVD.  starting  with  the  phase  with  the  highest 
PVD.  The  functions  PKhedulJi)  and  PfeasibleQ  construct  this  set25.  Given  a  set  of  A'  phases.  PscheduUJ,) 
will  first  (recursively)  determine  which  of  the  A-l  phases  with  the  greatest  potential  value  may  feasibly  be 
executed.  P scheduie/).  using  P foible 0  and  ultimately  feasiblei).  then  determines  if  the  phase  with  the  least 
potential  value  can  feasibly  be  added  to  the  set.  If  so,  it  is. 

Once  P schedule/^  ^as  identified  which  phases  can  be  completed  successfully,  it  is  fairly  straightforward  to 
determine  which  phase  should  be  executed  first.  The  auxiliary  function  DL^irst()  specifies  the  earliest 
deadline  that  must  be  met  by  those  phases  that  can  complete  execution.  That  information,  along  with  the 
set  of  phases  to  be  completed,  is  once  again  passed  to  the  function  mustfinishbyO  to  determine  all  of  the 
work  that  must  be  done  by  the  earliest  deadline.  And  finally,  pickoneQ  selects  a  mode-phase  pair  from  that 
set  to  execute  first,  pickone 0  always  prefers  to  complete  a  phase  normally  if  possible,  but  if  that  cannot  be 
done,  it  will  initiate  (or  continue)  the  abortiou  of  a  phase. 


32.2.  Observations  on  the  Definition 

Several  observations  can  be  made  now  that  the  formal  definition  af  the  DASA  Scheduling  Automaton  has 
been  presented  in  full.  Each  of  the  following  sections  focus  on  an  interesting  observation 


3.12.\.  Manifestation  of  Desirable  Properties 

Section  3.1.1  listed  five  desirable  properties  that  the  DASA  algorithm  should  possess.  Now  that  the 
algorithm  has  been  presented  in  some  depth,  those  properties  should  be  reviewed  again: 

1.  explicitly  account  for  dependencies  —  this  has  been  accomplished.  The  definition  of 
SelectPhasei)  was  described  from  the  bottom  up,  and  the  first  thing  that  was  done  in 
considenng  any  phase  was  to  determine  those  phases  that  it  depends  on  (us  dependency  list) 
and  the  aggregate  value  of  this  group  of  phases  to  the  application. 


J1ll  is  not  unexpected  that  both  the  completion  and  the  abortion  of  a  single  phase  will  sometimes  be  executed  In  the  expected  case, 
the  phase  is  aborted  in  order  to  allow  some  other  phase,  with  a  tighter  deadline,  to  execute.  Later,  the  aborted  phase  can  be  restarted 
and  completed  normally,  still  meeting  us  time  constraint. 

^Note  that  the  functions  that  are  named  Pfi  ail  represent  sets  of  phases. 
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2.  minimize  effort  —  this  property  refers  to  the  amount  of  effort  required  to  enable  a  phase  to  be 
ready  to  execute.  The  DASA  algorithm  has  minimized  this  effort  by  minimizing  the  time 
needed  to  eliminate  each  of  the  dependencies  for  that  phase:  if  it  is  quicker  to  abort  a  phase 
than  it  is  to  execute  it  to  completion,  than  it  is  aborted.  This  minimizes  a  latency,  of  sorts,  at 
the  possible  cost  of  later  reexecuting  phases  that  have  been  aborted. 

3.  maximize  retum/benefit  —  the  use  of  the  potential  value  density  addresses  this  concern 
directly.  As  outlined  in  Section  3.1.1,  by  adding  those  phase  groups  (a  phase  along  with  the 
phases  that  comprise  its  dependency  list)  with  the  highest  PVD  to  the  schedule  first,  the 
algorithm  guarantees  that  no  other  phase  group  can  attain  a  higher  aggregate  value  consuming 
the  same  number  of  cycles,  based  on  current  knowledge. 

4.  maximize  the  chance  of  meeting  deadlines  —  this  property  has  been  met  through  the 
placement  of  phases  in  the  tentative  schedule  that  is  recursively  constructed  by  SelectPhase (). 
The  key  observation  is  that,  although  phases  are  considered  for  addition  to  the  tentative 
schedule  in  order  of  decreasing  PVD,  they  are  actually  added  to  the  schedule  in  an  order  that 
is  determined  only  by  the  deadlines  of  the  phases  being  placed  and  their  dependencies:  stated 
informally,  a  phase  that  is  to  be  executed  to  completion  is  inserted  in  the  schedule  according 
to  its  deadline,  unless  that  time  is  too  late  to  allow  a  scheduled  phase  that  depends  on  it  to 
complete  in  rime.  In  the  latter  case,  it  inherits  the  latest  deadline  that  will  allow  the  dependent 
phase  to  meet  its  deadline. 

5.  globally  optimize  schedule  —  the  function  reduceQ  applies  some  global  reductions  to  the 
tentative  schedule  that  is  recursively  constructed  by  SelectPhase{).  This  is  necessary  since 
each  phase  is  added  to  the  schedule,  along  with  its  dependencies,  independendy  of  any  other 
phases  that  may  already  be  part  of  the  schedule.  As  a  result,  it  is  possible  that  the  abortion  of 
a  phase  may  be  scheduled  after  the  same  phase's  completion.  Although  this  would  have  no 
real  effect  on  the  sequence  of  phases  executed  —  after  the  phase  had  completed,  it  would 
release  all  of  the  shared  resources  it  was  holding  so  that  the  next  evaluation  of  SelectPhase{) 
would  have  no  dependency  requiring  its  abortion  —  it  is  important  to  eliminate  it  from  the 
tentative  schedule  so  that  the  most  realistic  estimate  of  processor  cycle  demands  can  be 
maintained. 


S2J..2.  Nondeterminism  in  Definition 

As  was  mentioned  in  Section  3.2. 1.3,  a  mathematical  form  was  chosen  for  the  function  definitions  in  part 
to  allow  orderings  to  be  specified  when  they  are  important,  and  to  be  unspecified  otherwise.  The 
definitions  of  SelectPhase{)  and  its  subsidiary  functions  provide  examples  of  each: 

•  Order  matters  when  determining  which  phases  to  add  to  the  tentative  schedule.  The  function 
P scheduled 0  selects  the  phase  to  be  removed  from  the  set  P  it  was  given  according  to  the  PVDs 
and  execution  clocks  of  the  individuals  phases  in  P.  (Even  here  there  is  some  nondeterminism, 
since  it  is  possible  —  though  probably  unlikely  —  for  more  than  one  phase  to  belong  to  the  set 
PteastPvO'  with  each  of  these  phases  having  the  same  PVD  and  execution  clock  value.) 

•  Order  does  not  matter  when  the  set  of  mode-phase  pairs  that  must  be  in  a  schedule  m  order  to 
successfully  complete  a  given  set  of  phases  is  constructed.  This  construction  is  carried  out  by 
the  function  tobescheduled(),  and  in  this  case,  the  phase  to  be  removed  from  the  set  P  for  the 
next  recursive  call  to  tobescheduled()  is  totally  unspecified  —  any  element  of  P  will  do. 


There  are  other  examples  for  each  of  these  cases  in  the  DASA  definition,  but  these  serve  to  illustrate  the 
ability  of  the  notation  to  capture  the  essential  aspects  of  ordering  without  imposing  unnecessary  constraints. 
This  clarity  may  be  of  considerable  benefit  when  weighing  the  correctness  of  alternative  implementations 
of  the  algorithm  that  use  different  orderings  for  various  evaluations. 


Scheduling  Dependent  Real-Time  Activities 


C-59 


3.2.2.3.  Explicit  Appearance  of  Time 

Time  doesn't  explicitly  appear  in  many  of  the  individual  function  definitions.  This  may  be  unexpected 
for  an  environment  where  time  —  and  meeting  time  constraints  —  is  a  central  concern.  Of  necessity,  time 
explicitly  plays  a  role  in  testing  the  feasibility  of  executing  groups  of  phases.  And  while  this  testing  occurs 
throughtout  the  evaluation  of  SelectPhase ().  references  to  time  seem  infrequent  since  phases  are  added  to 
the  tentative  schedule  according  to  their  potential  value  density,  not  according  to  the  urgency  of  their  time 
constraints. 

3J.  Scheduling  Example  Revisited 

Now  that  the  scheduling  algorithm  has  been  presented,  it  is  possible  to  reconsider  the  scheduling  example 
discussed  in  Section  1.3.  Once  again,  the  problem  is  to  schedule  phases  pa,  pb<  and  pc  so  as  to  meet  their 
time  constraints,  if  possible.  In  fact,  it  is  possible,  and  this  is  shown  by  the  bottom  execution  profile  in 
Figure  3-7.  Notice  that  phase  pa  is  aborted  during  the  course  of  execution,  thus  allowing  phase  pb  to  meet 
its  deadline.  This  necessitates  the  reexecunon  of  the  start  of  phase  pa  at  a  later  time. 

The  top  of  Figure  3-7  shows  the  execution  profile  for  a  scheduler  that  is  identical  to  DASA,  except  that  it 
cannot  abort  phases.  It,  too.  meets  all  of  the  deadlines,  while  consuming  fewer  cycles  than  DASA  in  the 
process.  However,  it  must  tolerate  a  longer  delay  between  the  time  that  it  determines  that  a  given  phase 
should  be  executed  and  the  time  at  which  that  phase  may  actually  begin  execution  due  to  existing 
dependencies  This  variant  of  the  DASA  algonthm  is  shown  only  as  a  reference  point.  At  this  point,  it  is 
not  anticipated  that  it  will  studied  in  significant  depth  as  pan  of  the  proposed  thesis  research. 
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Figure  3-7:  Execution  Profiles  for  DASA  Scheduler  with  and  without  Aborts 
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Chapter  4 
Analytic  Results 


This  chapter  presents  a  set  of  analytic  results  that  argue  for  the  benefits  of  the  dasa  algorithm  First,  a 
number  of  high-level  requirements  that  real-time  scheduling  algorithms  must  possess  is  discussed.  Then  a 
strategy  for  demonstrating  that  the  dasa  schedubng  algorithm  possess  those  properties  is  outlined, 
followed  by  a  set  of  proofs  conforming  to  that  strategy.  The  final  section  of  the  chapter  discusses  various 
interesting  behaviors  that  the  Dasa  algonthm  may  demonstrate,  which  are  revealed  by  its  formal 
descnption. 

4.1.  Requirements  for  Scheduling  Algorithms 

Ary  pracucal  solution  to  the  problem  of  scheduling  while  taking  dependencies  into  account  must  be 
correct,  valuable,  and  tractable. 

The  solution  must  be  correct  Specifically,  any  scheduling  decisions  that  are  made  must  observe  all  of 
the  known  dependencies.  Therefore,  for  instance,  any  activity  that  is  selected  to  execute  must  be  able  to 
execute  at  that  point  in  time.  The  solution  must  also  orey  the  concurrency  control  rules  of  the  model,  in 
particular,  for  the  model  presented  here,  mutually  exclusive  access  to  the  shared  resources  must  be 
guaranteed. 

The  solution  must  be  valuable.  When  cast  in  the  computational  model  dcscnbed  above,  this  requirement 
simply  means  that  the  schedules  dictated  by  the  scheduler  must  yield  good  values  relative  to  other 
scheduling  algorithms.  Notice  that  this  is  partially  a  comment  on  the  scheduler's  behavior  in  normal 
situations  and  partially  a  comment  on  its  behavior  in  overload  situations.  In  normal  (non-overload) 
situations,  the  ordenng  of  activities  is  critical  and  many  schedulers  will  not  order  them  appropriately,  even 
when  there  are  sufficient  processor  cycles  present  to  satisfy  all  demands;  in  overload  situations,  the 
system/application  should  display  a  graceful  degradation  of  function*6.  Both  of  these  types  of  situation  are 
accurately  gauged  by  the  value  metric  previously  introduced. 

Finally,  the  solution  must  be  computationally  tractable' efficient.  That  is.  the  solution  must  coasume,  at 
worst,  an  amount  of  time  and  space  that  is  polynomial  m  the  problem  sire  —  in  this  case,  the  problem’s 
size  is  the  number  of  phases  under  consideration  by  the  scheduler. 


l6Hvcn  schedulers  thal  lake  dependencies  into  account  rna)  handle  overload  situations  ditterentk.  resulting  m  different  scheduling 
decisions,  and  hence  different  values,  for  executing  the  application 
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4.2.  Strategy  for  Demonstrating  Requirement  Satisfaction 

Analytic  proofs  have  been  constructed  to  demonstrate  the  correctness,  value,  and  tractabilitv  of  the  Dasa 
algorithm.  These  proofs  are  contained  in  Section  4.3. 

To  demonstrate  correctness,  it  is  shown  that  the  dasa  algorithm  respects  any  existing  dependencies 
among  phases  and  makes  legal  selections.  This  is  accomplished  by  demonstrating  that  any  phase  that  Dasa 
selects  for  execution  is  capable  of  executing  immediately.  That  is,  it  is  shown  that  dasa  will  either  (1) 
select  a  phase  that  is  ready  to  run  (i.e.,  is  not  blocked),  or  (2)  designate  that  a  phase  is  to  be  aborted,  which 
can  be  executed  immediately  for  any  phase,  blocked  or  ready  to  run.  This  proof  is  presented  in  Section 
4.3.1. 

To  demonstrate  value,  proofs  serve  to  illustrate  that  Dasa  performs  well  when  compared  to  other 
scheduling  algorithms  in  appropriate  situations.  In  particular,  when  there  are  no  dependency 
considerations,  dasa  can  be  compared  to  a  number  of  well-known  algorithms.  In  fact,  it  is  shown  that,  if 
there  are  no  overload  conditions,  the  Dasa  automaton  will  accept  the  same  histories  as  an  automaton  that 
accepts  histones  conforming  to  Locke's  Best  Effort  Scheduling  Algorithm  (LBESA).  Not  coincidentally, 
this  is  simply  a  deadline-ordered  history.  In  overload  situations,  it  is  demonstrated  that  the  dasa 
automaton  will  accept  histones  that  the  LBESA  automaton  will  not  accept,  and  that  these  histories  may  have 
a  higher  value  than  any  history  that  the  LBESA  automaton  may  accept  involving  the  same  phases  with  the 
same  scheduling  parameters.  These  proofs  are  presented  in  Section  4.3.2. 

To  demonstrate  tractabihty,  a  procedural  version  of  the  DASA  algonthm  has  been  developed,  and  its 
complexity  has  been  analyzed  to  prove  that  the  time  and  space  requirements  of  the  algonthm  are  indeed 
polynomial  in  problem  size  —  that  is,  that  the  lime  and  space  required  to  execute  the  algonthm  are  each 
proportional  to  the  number  of  active  phases  raised  to  some  polynomial  power.  Both  the  procedural  version 
of  the  Dasa  algorithm  and  the  denvation  of  its  space  and  time  properties  are  presented  in  Section  4. 3. 3. 


4.3.  Proofs  of  Properties 

The  proofs  in  the  sections  that  follow  demonstrate  propeilics  of  the  Dasa  scheduling  algorithm  according 
to  the  strategy  outlined  in  the  preceding  section.  Each  section  contains  all  of  the  proofs  corresponding  to  a 
single  property  of  concern.  In  addition  to  the  proofs  themselves,  other  material  that  must  be  developed  to 
complete  the  proofs  is  also  presented.  For  example,  in  Section  4.3.2. 1,  a  derivation  of  another  scheduling 
automaton  is  presented.  This  automaton  is  subsequently  used  in  proofs  to  assess  the  utility  of  the  dasa 
algonthm. 
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4J.1.  Algorithm  Correctness 

There  is  only  one  proof  in  this  section  It  demonstrates  that  dasa  respects  all  existing  dependencies 
among  phases  by  showing  that  the  phase  selected  for  execution  can  execute  immediately.  Therefore,  no 
phase  is  ever  selected  for  normal  execution  if  it  is  dependent  on  some  other  execution.  Of  course,  a  phase 
that  ts  blocked  due  to  a  dependency  could  be  selected  to  abort,  since  it  can  abort  at  any  time  regardless  of 
dependency  considerations. 


4.3.1. 1.  Proof:  Selected  Phases  May  Execute  Immediately 

Theorem  1:  Given  PhaseList,  the  set  of  phases  known  to  the  dasa  automaton,  prove  that  the  phase 
selected  for  execution.  PhaseElect,  is  eligible  to  run  at  that  point. 

Proof.  In  every  case  in  the  dasa  automaton.  PhaseElect.  the  phase  selected  for  execution,  is  determined 
by  evaluating  SelectPhase{PhaseList).  The  function  SelectPhaseQ  is  defined  as: 

SelectPhase(P)  = 

pickone(mustfimshb\iDLfirs,(pmplist)J,schedule/P))). 

where 

pmphst  =tobescheduled(P  schedulefP)) 


and  pickone ()  is  defined  as 
pickone(PMP)  = 

<ncr  jl.p>,  if  <normal,p>  €  PMP 

ADep(p)=nullphase 

<abort,p>,  if<abortp>£  PMP 

/ \—>(5q){<normal.q>e  PMP 
rd)ep(q)=nullphase) 

<normal.nullphase>,  otherwise 


Notice  that  ptckoneQ  will  return  one  of  three  values: 

•  <normalp>.  for  some  phase  p  —  this  occurs  only  when  Depip )  =  nullphase ;  in  that  case,  p  is 
ready  to  run  by  definition. 

•  <abortp>.  for  some  phase  p  —  any  phase  may  be  aborted  at  any  time,  even  if  it  had 
previously  been  waiting  to  access  a  shared  resource;  so  once  again,  by  defimuon.  p  is  ready  to 
run. 

•  <normal.nullphase>  —  this  designates  an  idling  condinon,  which  is  always  possible,  so 
nullphase  is  tnviallv  ready  to  run*  . 


Ln  each  case,  PhaseElect  is  assigned  a  phase/mode  pair  in  which  the  phase  is  ready  to  run. 

|  EndO [Proof 


*  Notrce  that  <normal,nuUphase>  is  returned  onjy  in  the  case  that  there  are  no  phases  ready  to  run  in  either  their  normal  mode  or 
their  abort  mode 
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4J .2.  Algorithm  Value 

Since  most  scheduling  algorithms  do  not  utilize  dependency  information,  it  is  difficult  to  make  fair 
comparisons  between  their  performance  and  that  of  dasa  when  dependencies  are  involved.  Therefore,  this 
section  will  compare  Dasa  to  an  another  algorithm  (LBESA)  in  the  absence  of  any  dependencies. 

Since  LBESA  was  shown  in  to  outperform  a  number  of  standard  algorithms  in  a  range  of  situations,  a 
favorable  comparison  with  LBESA  will  demonstrate  that  dasa  behaves  well. 

To  that  end,  the  two  proofs  presented  in  this  section  demonstrate  that  the  dasa  algorithm  performs  well 
when  compared  to  the  LBESA  algorithm.  They  consider  a  set  of  activities  that  are  independent  of  one 
another,  each  of  which  is  described  by  a  time-value  funcnon  that  is  a  step  function.  They  show: 

1.  If  there  is  no  overload,  then  both  dasa  and  lbesa  yield  identical  expected  value  to  the 
application. 

2.  Under  overload,  dasa  may  schedule  more  activities  than  LBESA,  yielding  a  greater  expected 
value  than  lbesa. 

Before  presenting  the  two  proofs,  the  next  two  sections  develop  the  formal  scheduling  automata  that  they 
will  use.  First,  Section  4.3.2. 1  presents  the  lbesa  Scheduling  Automaton.  Then  Section  4. 3.2.2  presents  a 
scheduling  automaton  corresponding  to  the  dasa  algorithm  when  there  are  no  dependencies  to  consider. 

4.3.2.I.  LBESA  Scheduling  Automaton 

The  lbesa  Scheduling  Automaton  is  cast  using  the  General  Scheduling  Automaton  Framework  descnbed 
in  Section  2.3.2.  Once  again,  each  scheduling  decision  is  made  based  on  the  set  of  phases  currently  known 
to  the  automaton:  ( Po-Pi-Pg >  •  •  •  }■ 

LBESA  Automaton  State  Components.  The  state  components  associated  with  the  lbesa  Scheduling 
Automaton  are  presented  in  Figure  4-1.  They  are  simply  the  General  State  Components  that  every 
scheduling  automaton  contains,  and  they  were  descnbed  in  detail  in  Section  2. 3. 2. 9. 

Operations  Accepted  by  LBESA  Automaton.  The  operations  accepted  by  the  lbesa  automaton  and  their 
preconditions  and  postconditions  are  shown  ui  Figure  4-2. 

These  are  a  somewhat  simpler  version  of  those  presented  m  Section  3. 2. 1.2  for  the  dasa  Scheduling 
Automaton.  Most  notably,  there  are  no  operations  for  dealing  with  resources  —  in  particular,  there  are  no 
’request’  and  ’grant’  operations.  (Of  course,  in  keeping  with  the  General  Scheduling  Automaton 
Framework,  these  operations  actually  exist  for  the  LBESA  Scheduling  Automaton.  However,  their 
preconditions  are  defined  to  be  false,  indicating  that  events  with  these  operauons  can  never  be  accepted  by 
the  LBESA  Scheduling  Automaton.)  In  addition,  there  are  no  postcondiuons  for  ’request-phase'  to  release 
previously  acquired  resources,  and  the  precondition  for  'resume-phase'  is  one  term  shorter. 

The  lbesa  Scheduling  Automaton  does  not  accept  ’abort-phase’  operations  either.  This  is  because  the 
lbesa  scheduling  algorithm  does  not  abort  activities  or  phases.  Such  aborts  arc  not  required  because  the 
activities  are  all  assumed  to  be  independent. 
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General  State  Components: 

•  ExecMode  PHASE— »MODE  (MODE  is  either  'normal'  or  'abort') 

•  ExecClock:  PHASE  -4  VIRTUAL-TIME 

•  AbortClock:  PHASE  ->  VIRTUAL-TIME 

•  ResumeTime:  PHASE  -» TIMESTAMP 

•  Value:  PHASE  — » (TIMESTAMP  — >  VALUE)  (initially  Valued)  =  0) 

•  Total:  VALUE  (initially  ’O’) 

•  Runnin^Phase.  PHASE  (initially  'nuliphase') 

•  PhaseElect:  MODE  x  PHASE  (initially  '<normal.  nullphaso'i 

•  PhaseList:  list  of  PHASE  (initially  'o') 

Algorithm-Specific  State  Components 

•  S' one 


Figure  4-1:  State  Components  of  lbesa  Scheduling  Automaton 

When  activities  are  not  independent,  then  aborts  must  be  introduced  into  the  model  Notice  that  this  does 
not  mean  that  the  scheduler  must  generate  abort  signals,  but  rather,  that  there  must  be  a  way  to  return 
shared  resources  to  acceptable  states  before  allowing  other  activities  to  acquire  them  and  to  return  the 
aborted  activity  to  a  known  state  (presumably  to  handle  an  abort  exception)  if  it  is  to  have  any  chance  at 
continuing  normal  execution. 

References  to  the  'AbortClock'  state  component  have  been  left  in  the  postconditions  for  the  'preempt- 
phase’  operation  merely  for  convenience  when  comparing  it  to  another  automaton.  Since  aborts  are  never 
used,  the  clause  that  deals  with  the  'AbortClock'  state  component  will  never  actually  have  an  effect. 

’SelectPhase 1  Function  for  LBESA  Automaton.  The  function  'SclectPhaseO'  embodies  the  lbesa 
scheduling  algorithm  in  this  scheduling  automaton,  just  as  the  identically-named  function  had  done  in  the 
dasa  Scheduling  Automaton.  Figure  4-3  shows  the  definition  of  this  function. 

Since  Locke  never  employed  such  formalisms  in  his  work,  he  never  provided  as  rigorous  a  definition  for 
his  scheduling  algorithm  as  the  one  shown  here.  And  he  certainly  never  provided  a  mathematical  function 
corresponding  to  his  definition.  As  a  result,  the  definition  shown  here  captures  Locke's  algorithm  in  this 

framework. 

There  arc  a  number  of  ways  of  defining  SelectPhase ().  and  the  one  chosen  parallels  the  structure  of  the 
SclectPhaseO  function  for  the  Dasa  Scheduling  Automaton  in  order  to  facilitate  comparisons  between 

them 
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•  request -phased,  texpecltd)  p 
precondinons: 

true  <N'o  preconditions  here  so  that  interrupts  and  other  new  phases 
can  occur  at  any  ume> 

postconditions: 

if  (RunningPhase  =  p)  then 

if  (ExecMode(p)  =  normal)  then 

Total'  =  Totai  +  Value(p)(tevem) 
else 

;no  value  for  aborted  phase 
;release  the  resources  acquired  during  the  phase 
;  involves  no  action  for  this  automaton 
Value'(p)  =  v 
ExecClock'(p)  =  tcxpected 
AbortClock'(p)  =  0 
ExecMode’(p)  =  normal 
mote  that  p  is  not  resource-waiting 

;make  sure  p  is  part  of  the  list  of  phases,  if  necessary 

if  (‘expend  >°)‘heD 

PhaseList-  =  PhaseList  o  { p } 

else 

PhaseList' =  PhaseList  -  (p ) 

Phase  Elect'  =SelectPhase(PhaseListr) 
if{p=Running  Phase)!  hen 

■.give  up  processor  until  next  'resume-phase' 

RunningP  hase^-nullphase 

else 

■.happened  under  interrupt — leave' RunningP base' alone 

•  ‘„en!  preempt -phaserp)  S: 

preconditions: 

(RunningP  hase=p)A.{RunningPhase  *  nullphase) 

A(RunmngPhase  *  Phase{PhaseElect)) 

postconditions: 

if  (ExecMode(p)  =  normal)  then 

ExecClock’(p)  =  ExecClock(p)  -  (t  -  ResumeTime(p)) 

else 

AbortQock'(p)  =  AbortGock(p)  -  (tevem  -  RcsumeTime(p)) 

mote  p  is  not  resource-waiting 
RunningP  has  e'=nullphase 

•  t^.ent  resume-phase(p)  S: 

preconditions: 

(RunningP  has  e=nullphase)/\(P  haseiP  has  eElect)=p) 

/ \(P hase( P haseElect )  *  nullphase)r\(Mode(P  haseElect)=normal) 

postconditions: 

ResumeTime'(p)  =  t  m 
R  unntngP  has  e'=Phase(  Phase  Elect) 


Figure  4-2:  Operauons  Accepted  by  LBtiSA  Scheduling  Automaton 
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SelectPhase(Pi  = 

pickone(mustfuushb\(DL^ri,(pmphsn.P  schedl4leJP)\), 
where 

pmplist  =tobescheduled(P scheduUJ(P)) 


pickone(PMP)  = 

<normal.nullphase>.  if  PMP=0 

<normalj»  \  <normalp>  e  PMP,  otherwise 


DL 


first 


oo  ( 


(PMP)  = 

if  PMP=C 


Deadhne(p)  \  (<normal.p>  6  PMP) 

a(V q)(<normal,q> €  — » Deadline! q)> Deadlinetp)), 

otherwise 


P  schedulcJ'P'1  ~ 

O,  if  />=<i 

P schtdulJ  f’-iPlMpl). 

Pfexs\hlJ'P^  =  °- 

P,  if feasible(P) 

V^>(/M;,,)'Wherepe  Pleas,P^P^ 


^P€  P lastDlSP') 

ifP=0 

otherwise 


P«stDl(P)=  *■  l(P=« 

[p  |  (pe  /,)A(V<jp)[-7e  P  ~>((Deadline(p)>DeadItne(q)) 
/\(Deadline(p)=Deadline(q)  PVD(p)<PVD(q)))] ), 
otherwise 

puaxP\<p)  =  *-  lf/,=6 

ip  I  (p  e  F)  a  (VpXp  €  P  ->  ((PVD(p)  <  PVD(q)) 

a  (PVD(p)=PVD(q)  ->  ExecClockip )  <  £recC/oc-t(^)))), 
otherwise 


tobescheduled(P)  =  ( <normal,p>  \  p  e  P  | 
music  ompletebyitj3)  - 

jp  |  [pe  Pc£>eadhne(p)<t]\. 


otherwise 


mustfinishby(lj>)  = 

0.  if  /,=0vr</rvMf 

v  mustcompleteb\(t  J>)=o 

\<normalp>  \  p  e  mustcompletebvUj’ )),  Otherwise 


feasiblc(P)  =  rn/e.iff  (Vr)[(7>  t  )  —*  nmerequiredby(musifinishby(i.P))  <  (f— f 


nmerequiredby(PMP)  = 

0.  if  PMP=P 

Ej;ecClock<p)+timerequiredby(PMP-{<noriruilp>  ) ),  if  <normalp>  e  PMP 


PVD(p)  =  VDlp)  = 


Val(p) 

ExecClockip) 


Figure  4-3:  Functional  Form  of  I.BHSA  Algorithm 
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Despite  tne  degree  to  which  the  effort  to  cast  these  functions  in  the  same  form  succeeded,  there  are  still 
substantial  differences  between  the  two  functions.  The  most  important  of  these  is  the  order  in  w  hich  phases 
are  added  to  the  tentative  schedule  by  the  two  algorithms.  This  difference  is  seen  in  the  P  scheduled 
subsidiary  function  of  each  definition.  LBESA  adds  phases  to  the  tentative  schedule  in  deadline  order, 
nearest  deadline  first,  dasa,  on  the  other  hand,  adds  phases  to  the  tentative  schedule  in  order  of  decreasing 
potential  value  density. 

In  the  event  that  a  tentative  schedule  is  not  feasible,  both  algorithms  (effectively)  remove  phases  from  the 
tentative  schedule  in  order  of  increasing  value  density  or  potential  value  density,  respectively.  The  fact  that 
LBESA  adds  phases  to  the  schedule  based  on  one  attribute  and  sheds  phases  based  on  another,  while  dasa 
uses  a  single  attribute  for  both  purposes,  causes  the  algorithms  to  make  different  scheduling  decisions 
under  certain  circumstances.  This  leads  directly  to  the  fact  that,  under  overload,  dasa  can  attain  greater 
value  for  an  application  than  lbesa  can,  as  is  shown  in  Section  4. 3. 2.4. 

Locke  was  silent  on  some  details  concerning  his  algorithm,  such  as  which  phase  should  be  selected  if  two 
or  more  phases  shared  the  nearest  deadline  in  a  schedule  or  which  phase  to  shed  if  two  or  more  phases  had 
a  common  value  density  that  was  lower  than  that  of  all  of  the  others  phases  in  the  tentative  schedule. 
Whenever  possible,  these  details  have  been  resolved  in  the  manner  that  seemed  to  make  the  most  sense. 
For  example,  when  two  or  more  phases  are  characterized  by  the  same  value  density,  the  phase  requiring  the 
least  compulation  time  is  deemed  to  be  less  valuable  than  the  others  since  its  contribution  to  the  overall 
value  of  the  application  is  a  product  of  value  density  times  required  computation  ume.  If  two  or  more 
phases  share  the  same  value  density  and  the  same  required  computation  time,  then  any  of  the  phases  may 
be  chosen. 

4_3.2.2.  DASA/ND  Scheduling  Automaton 

The  dasa/nd'-8  Scheduling  Automaton  embodies  the  simplifications  to  the  dasa  Scheduling  Automaton 
that  can  be  made  when  there  are  no  dependency  issues  to  consider.  The  derivation  of  this  simplified 
automaton  appears  in  Appendix  B  For  the  sake  of  convenience,  the  resulting  automaton  is  presented  in 
this  section. 

As  before,  each  scheduling  decision  is  made  based  on  the  set  of  phases  currently  known  to  the  automaton 
and  designated  as  the  set  \p0,  pr  p,,  ...  J. 

DASA/ND  Automaton  State  Components.  The  state  components  associated  with  the  DASAyXD  scheduling 
automaton  are  presented  in  Figure  4-4.  Since  the  algorithm-specific  state  components  of  the  dasa 
Scheduling  Automaton  are  all  used  to  handle  resources,  they  have  been  omitted  in  the  dasand  Scheduling 
Automaton,  leaving  only  the  General  Slate  Components  found  in  every  scheduling  automaton.  (See 
Section  2. 3. 2. 9.) 


**Da$a/no  stands  for  dasa/No  Dependencies. 
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General  State  Components: 

•  ExecMode:  PHASE  — » MODE  (MODE  is  either  'normal'  or  'abort') 

•  ExecClock:  PHASE  ->  VIRTUAL-TIME 

•  AbortClock:  PHASE  -»  VIRTUAL- TIME 

•  ResumeTime:  PHASE— >  TIMESTAMP 

•  Value:  PHASE  — »(TIMEST AMP— >  VALUE)  (initially  Valued)  =  0) 

•  Total:  VALUE  (initially  ’O') 

•  RunningPhase:  PHASE  (initially  ’nullphase') 

•  PhaseElect:  MODE  x  PHASE  (initially  'cnormal.  nullphase>’) 

•  PhaseList:  list  of  PHASE  (initially  ’6’) 

Algorithm-Specific  State  Components: 

•  None 


Figure  4-4:  State  Components  of  DAS.a/Nl.  Scheduling  Automaton 

Operations  Accepted  by  DASA/ND  Automaton  The  operations  recognized  by  the  Das  A/ND  Scheduling 
Automaton  and  their  precondiuons  and  postconditions  are  shown  in  Figure  4-5. 

Once  again,  these  are  simpler  than  those  shown  previously  for  t)  Dasa  Scheduling  Automaton  in 
Section  3. 2, 1,2.  In  fact,  largely  because  the  automaton  docs  not  have  to  handle  dependencies  and  aborts, 
this  set  of  operation  specifications  is  identical  to  that  shown  in  the  previous  section  for  the  LB  ESA 
Scheduling  Automaton  Nonetheless,  the  two  automata  a  '  not  identical  since  their  'SelectPhaseO' 
functions  differ  significantly. 

’SelectPhase'  Function  for  DASANiD  Automaton  Figure  4-6  shows  the  definition  ot  the  ’SelectPhaseO’ 
function  for  the  Dasa/ND  Scheduling  Automaton 

This  definition  is  structurally  similar  to  the  definition  for  'SelectPhaseO’  found  in  the  LB  ESA  Scheduling 
Automaton.  But.  although  many  of  the  functions  arc  identical,  there  are  some  critical  differences. 

The  most  noticeable  ^  Terence  is  the  absence  of  the  subsidiary  function  P  f0iO.  which  locales  the  phase 
with  the  latest  deadline.  A  less  noticeable  difference  is  invocation  of  PieaitPV 0,  rather  than  P lastDL{)-  in  the 
definition  of  P  schtdultJ)-  In  fact,  it  is  PscheduitJ.)  that  orders  die  phases  as  they  arc  added  to  a  tentative 
schedule  for  both  the  lbesa  and  the  dasaad  Scheduling  Automata  Since  the  Dasa/nd  Scheduling 
Automaton  adds  phases  to  the  schedule  in  order  of  decreasing  potential  value  density,  it  has  no  need  for 

PIosidS)- 
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•  'even,  request-phasetv,  texpecled)P: 

preconditions: 

true  <No  preconditions  here  so  that  interrupts  and  other  new  phases 
can  occur  at  any  time> 

postconditions: 

if  (RunrungPhase  =  p)  then 

if  (ExecMode(p)  =  normal)  then 

Total’  =  Total  +  Value(p)(tcvcnl) 
else 

;no  value  for  aborted  phase 
trelease  the  resources  acquired  during  the  phase 
; involves  no  action  for  this  simplified  automaton 
Value  '(p)  =  v 
ExecGock’(p)  =  texpecled 
AbortClock’(p)  =  0 
ExecMode’fp)  =  normal 
mote  that  p  is  not  resource-waiting 

.make  sure  p  is  part  of  the  list  of  phases,  if  necessary 

lf(,„pcctcd>°)thea 

PhaseList'  =  PhaseList  {p  f 

else 

PhaseList’  =  PhaseList  -  { p } 

Phase  Elect'  =SelecrPhase(PhaseList') 
if{p=RunningPhase)then 

; give  up  processor  until  next  'resume-phase' 

RunmngP  hase^nullphase 

else 

; happened  under  interrupt — leave' RunmngP hase' alone 

•  'event  PreemP'-PhaSe(P)  S: 

preconditions: 

(RunmngP  hase^p)A.(RunmngP  hase  *  nullphase) 

MRunningPhase  *  Phase(PhaseElect )) 

postconditions. 

if  (ExecMode(p)  =  normal)  then 

ExecClock'(p)  =  ExecGock(p)  -  (tcvenl  -  ResumeTime(p)) 

else 

AbortGock’(p)  =  AbortGock(p)  -  (tevem  -  ResumeTime(p)) 

mote  p  is  not  resource-waiting 
RunmngP  has  e'=nullphase 

•  t(veni  resume-phase(p)  S: 

preconditions: 

(RunmngP  hase=nullpkase)A(Phase{PhaseElect)=p) 

/ \(Phase(PhaseElect )  *  nullphase)A(Mode(PhaseElect)=normal) 

postconditions: 

ResumeTime’(p)  =  teven, 

RunningPhase'=Phase(P  hase  Elect) 


Figure  4-5:  Operations  Accepted  by  das  a/nd  Scheduling  Automaton 
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SelectPhaseiP)  = 

piekone(mustfimshby(DLfirs!(pmplist)J,schedu.'/P ))), 

where 

pmplist  =tobescheduled(Psch'dulJP)) 
pickone(PMP)  = 

<normal.nu\lphase>,  if  PMP=0 

<normal,p>  \  <normalp>  e  PMP,  otherwise 

DL.JPMP)  = 

o°.  if  PMP  =0 

Deadhneip)  \  (<normal p>  £  PMP) 

a(V q)(<normal.q>  6  PM/1  — » Deadline(q)>  Deadhneip)), 

otherwise 


P  ichtduJcJ  P)  ~ 

0, 

IMP !  )• 


P!eanhlJ'P)  ~  6- 


)•  where p  e  PkauPXAP). 


if  P=6 

if>ePw>v<P) 

ifP=0 

if/easii>/e(P) 

otherwise 


P lrnrtP\tP)  ~ 


(p  I  (p  6  P)  A  (VfX? e  P  -*  i(PVD(p)< PVD(q)) 

a  (PVDip)-PVDiq)  — >  ExecClock(p)<ExecClockiq)))), 

otherwise 


tobescheduled(P)  -  ( <normal.p>  \  p  e  P } 

mustcompleteby(t.P)  = 

0. 

(p  I  [p  6  P rJDeadhneip)  <  t]  | , 


otherwise 


mustfimshbvit.P)  - 

0, 


{<normal,p>  \  p6  mustcompleteby(tj’)}. 


if  P=0  v  t<tevenl 

v  mustcompletebyit  ,P)=d 
otherwise 


feasibleiP )  =true,  iff  (Vt)[(t>tri,en|)—>tlmerequiredby{must^lntshbyUJ,))  <  (l~tevenl)] 
amerequiredby(PMP)  = 

0.  if  PMP  =6 

ExecClock(p)-¥timerequtredby(PMP-\<normal,p>\).  if  <normal.p>  e  PMP 


PVD{p) 


Valip) 

ExecClockip) 


Figure  4-6:  Functional  Form  of  dasaad  Algonthm 
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As  was  mentioned  in  the  previous  section,  this  difference  in  schedule  construction  may  allow  the 
DAS a/ND  Scheduling  Automaton  to  accumulate  a  higher  value  for  an  application  than  the  lbesa  Scheduling 
Automaton.  This  will  be  illustrated  by  the  proof  in  Section  43.2.4. 

43.2.3.  Proof:  If  No  Overloads,  c{DASA}  and  LBESA  Are  Equivalent 

The  introduction  of  the  two  scheduling  automata  in  the  previous  sections  has  set  the  stage  for  the  proofs 
in  this  section  and  the  next.  The  proof  that  follows  demonstrates  that  if  there  are  no  overloads,  then  both 
automata  will  accumulate  the  same  value  for  the  applicaoon  —  that  is.  both  algorithms  will  make  the  same 
scheduling  decisions.  In  fact,  both  automata  will  accept  the  same  sequence  ot  events  as  the  scheduling 
automaton  embodying  a  deadline  scheduler.  As  stated  earlier,  a  deadline-ordered  schedule  is  known  to  be 
optimal  for  a  uniprocessor  when  there  are  no  overloads. 

Theorem  2:  Consider  (1)  a  set  of  independent  activities  each  comprising  a  single  computational  phase 
that  is  characterized  by  a  simple  time-value  function  —  a  step  function  with  a  positive  value  before  a 
designated  critical  ume  and  a  value  of  zero  after  that  time  (that  is.  each  phase  has  a  hard  deadline!  — 
where  (2)  there  are  sufficient  processor  cycles  to  allow  all  of  the  phases  to  meet  them  deadlines.  Given  two 
automata,  one  designated  dasa  that  accepts  histones  corresponding  to  schedules  generated  by  the  dasa 
Scheduling  with  Dependencies  Algonthm  and  one  designated  lbesa  that  accepts  histones  corresponding  to 
schedules  generated  by  Locke's  Best  Effort  Scheduling  Algonthm,  show  that  whenever  il)  and  (2)  hold, 
every  history  that  is  accepted  by  L3ESA  is  also  accepted  by  dasa  that  has  equal  value.  Thus  both  automata 
yield  equal  value  for  each  such  history. 

Proof.  For  the  sake  of  simplicity,  since  LBESA  cannot  handle  dependencies  among  phases,  this  proof  will 
be  carried  out  by  companng  the  lbesa  automaton  with  the  dasa^nd  automaton  —  a  simplified  version  of 
the  dasa  Scheduling  Automaton  that  contains  no  dependency  considerations.  The  dasa/ND  automaton  is 
defined  in  Section  43.2.2.  Furthermore,  the  only  histones  being  examined  by  the  automata  are  histones 
that  do  not  involve  overload  situations. 

Proof  by  induction. 

Basis.  Show  that  (1)  if  lbesa  accepts  the  first  event  in  a  history,  das.and  will  also  accept  it.  (2) 
RunningPhase.  PhaseList,  PhaseElect.  and  Total  are  the  same  for  both  automata,  and  ( 3)  Value.  ExccClock , 
ExecMode,  and  ResumeTime  are  the  same  for  each  active  phase  in  both  automata 

Initially, 

>  RunmngPhase^nullphase 
PhaseList=i> 

PhaseElect~<normal.nullphase> 

Total^Q 

As  a  result,  the  only  event  whose  precondition  for  lbesa  may  be  satisfied  is  'request-phase.'  Therefore, 
the  first  event  in  any  history  that  L3ESA  will  accept  must  be  a  'request-phase.' 
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In  that  case,  let  the  first  event  in  the  history  be: 

^rveni\  request-phase(v,texpeclfdl)  />, 

LBESa  accepts  this  event  —  its  precondition  for  accepting  it  is  true  —  and  as  part  of  its  postconditions,  it 
sets: 

Totaf =0 
Value' (p^)=v 
ExecClock' (p^)=teipeaed , 

ExecMode' ip  |  )= normal 
PhaseList'=[p , ) 

PhaseElect’=SelectPhase{P  base  List) 

=  <normal.px>.  if feasibte({p  .  j) 

<normal,nullphase> .  otherwise 

Dasa/ND  also  accepts  this  event  —  its  precondition  is  also  true  —  and,  the  state  component  changes 
induced  by  the  postconditions  for  the  event  include  those  made  by  lbesa. 

Therefore,  dasa/nd  accepts  the  first  event  in  any  history  accepted  by  lbesa.  Furthermore, 
RunmngPhase,  PhaseList.  PhaseElect ,  and  Total  are  idenocal  in  both  automata  after  accepting  this  event. 
And  finally,  Value.  ExecClock.  and  ExecMode  are  the  same  in  both  automata  after  accepting  the  event  for 
the  only  currently  active  phase,  py  while  ResumeTime  is  not  yet  defined  for  any  phase  in  either  automata 
—  and  so  is  trivially  the  same  in  both. 

Inductive  Step.  Given  that  dasa/nd  has  accepted  the  first  n  events  in  a  history  that  lbesa  accepts:  that 
RunmngPhase .  PhaseList.  PhaseElect.  and  Total  are  the  same  for  both  automata  after  accepting  those 
events:  and  that  Value.  ExecClock.  ExecMode.  and  ResumeTime  arc  the  same  in  both  automata  for  each 
active  phase  after  accepting  those  events,  show  that  dasa/nd  will  also  accept  the  n+ls'  event  in  the  history 
if  LBESA  accepts  it,  that  RunmngPhase.  PhaseList.  PhaseElect.  and  Total  will  be  the  same  in  each 
automaton  after  that  event  is  accepted,  and  that  Value.  ExecClock.  ExecMode.  and  ResumeTime  will  be  the 
same  in  each  automaton  for  each  acnve  phase  after  the  n+15'  event  is  accepted. 

LBESA  may  accept  any  event  for  which  the  precondition  is  satisfied  In  thus  case,  it  may  accept  an 

appropriate 

•  ’preempt-phase’ 

•  ’resume-phase’ 

•  ’request-phase’ 

The  precondition  for  accepting  each  of  these  events  is  the  same  m  both  automata  The  preconditions 
depend  only  on  the  values  of  RunmngPhase .  PhaseElect.  and  the  parameter  p.  Hence  if  lbesa  accepts  the 
n+lsl  event,  Dasa/nd  will  also  accept  it  since,  by  inductive  hypothesis,  it  has  the  same  values  for  the 
relevant  state  components,  the  same  parameter  values,  and  the  same  precondition  as  lbesa. 


Next,  it  should  be  demonstrated  that  RunmngPhase.  PhaseList.  PhaseElect.  and  Total  arc  tlx:  same  for 
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both  automata  after  the  n  +  Js‘  event  is  accepted,  and  that  Value.  ExecClock,  ELxecMode,  and  ResumeTime 
are  the  same  for  both  automata  for  each  active  phase  after  that  event  is  accepted. 


Consider  each  of  the  three  possible  events: 

1.  'preempt-phase'  —  in  both  automata.  RunningPhase'  is  set  to  nullphase  while  PhaseElect 
remains  unchanged,  and  therefore  equal.  Also  in  both  automata,  ExecClock' ip)  is 
conditionally  assigned  a  new  value.  In  both  automata,  the  condition  — 
ExecModeip)=normal  —  is  ldenncal,  p  is  the  same  in  both  since  it  is  part  of  the  n  +  lsl  event, 
and  by  inductive  assumption  E\ecMode{p)  is  the  same  in  both  automata  Consequently, 
either  both  or  neither  of  the  automata  will  update  ExecClock' Ip).  Finally,  note  that  the 
formula  used  to  update  ExecClock'ip)  is  the  same  in  both  automata,  ExecClockip )  and 
ResumeTimeip)  are  the  same  in  both  automata  by  inductive  assumption,  and  rrifnI  is  the  same 
in  both  since  it  is  part  of  the  n  +  lst  event  and  so  is  independent  of  the  state  of  the  automata 
Therefore,  ExecClock'ip )  will  be  the  same  in  both  automata  if  it  is  updated. 

2.  'resume-phase'  —  in  both  automata  RunningPhase  is  set  to  PhaseElect.  which  has  the  same 
value  in  both  automata  after  accepting  the  first  n  events,  while  PhaseElect  remains 
unchanged,  and  therefore  equal,  in  both  automata.  .Also,  ResumeTime' ip)  is  set  to  t  .  This 
assignment  results  in  the  same  state  for  ResumeTime'ip )  in  both  automata  since  ResumeTime 
was  the  same  in  both  automata  for  all  active  phases  after  the  first  n  events  had  been  accepted 
and  t  is  the  same  for  both  automata  because  it  is  part  of  the  n  +  l!l  event  and  so  is 
independent  of  the  states  of  the  automata. 

3.  request-phase’  — 

•  RunningPhase'.  in  both  automata,  RunningPhase’  may  condinonally  be  set  to  nullphase: 
in  each  automaton,  the  condition  under  which  this  is  done  —  p-RunnmgPhase  —  is 
the  same.  RunningPhase  is  the  same  by  inducuve  hypothesis,  and  p  is  the  same  since  it 
is  pan  of  the  n  +  lsl  event  and  has  a  value  that  is  independent  of  the  state  of  the 
automaton. 

•  PhaseList:  in  both  automata,  PhaseLisT  will  conditionally  be  set  to  either 

PhaseListw\p)  or  PhaseList  -  {p).  in  each  automaton,  the  condition  under  which  this 
is  done  —  —  's  same,  PhaseList  is  the  same  by  inductive  hypothesis, 

and  p  and  tfxpecled  are  the  same  since  they  are  pan  of  the  n+/s'  event  and  have  values 
that  are  independent  of  the  state  of  the  automaton. 

•  PhaseElect:  in  both  automata.  PhaseElect'  is  set  to  SelectPhase(PhaseList').  As  argued 
in  the  previous  bullet.  PhaseList’  is  the  same  in  both  automata.  Now  consider  the 
function  SelectPhaseO  for  each  automaton.  Most  of  the  subordinate  functions  involved 
in  the  definition  of  SelectPhase( )  are  identical  in  both  automata.  In  fact  the  only 
subordinate  function  that  differs  is  P  sc),e<iulej0  —  although  the  form  is  the  same  in 
both,  the  specific  ordering  of  recursive  functional  evaluations  is  different  in  the  two 
automaton  definitions. 

It  is  given  that  there  are  sufficient  processor  cycles  available  to  allow  all  of  the  phases 
to  meet  all  of  their  deadlines.  In  terms  of  the  mathematical  formulation  of  these 
automata,  this  is  equivalent  to  saying  that  (VP)feasible(P)=true  —  that  is,  it  is  feasible 
to  schedule  all  of  the  known  phases  at  any  given  umcr9  In  that  case,  for  both  automata 
the  definition  of  PfeasMt 0  can  be  simplified  from 

Pfeas4>l/P^  ~  lfP=kl 

P.  dfeasible(P) 

p/«W/>-lf’>)-whercPe  Pi'as,p\ ^  othenv,se 


:<This  property  is  maintained  through  an  entire  history  because  both  automaia  accept  deadline -ordered  histones  if  there  are  no 
overload  conditions,  and  a  deadline-ordered  schedule  will  be  guaranteed  to  rr*ct  all  of  the  deadlines  if  there  are  sutficient  processing 
cycles  available. 
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to 

Pftasiblt(P^  =  °-  >fP=C 

P.  iffeasihle(P) 

and.  finally.  to 

P feasible^  =  P 

Since  PfeaSibie()  acts  as  an  idenoty  function,  the  definuon  of  P  scheduitjO  can  also  be 
simplified  from 

P  schtdulcJ'P  ^  ~ 

0.  i fP=0 

PfeasM/PscH<dujJP-{P\)^P))-  'tP  e  P+P) 

to 

P  schedultJ  pS>  = 

0.  i iP=6 

PscH,duiJP-{P)y^Pl  tips  PX(P) 

which  is  equivalent  to 

Pschtdute</P')  =  P 

Of  course,  the  defimnons  of  SelectPhaseO  for  both  automata  are  now-  exactly  the  same. 
The  evaluation  of  SelectPhaseiPhaseList")  depends  on  the  values  of  PhaseLisf. 
ExecClock' ,  and  Value',  all  of  which  are  shown  to  be  the  same  for  both  automata  after 
the  n+1  st  event  in  the  history  is  accepted.  The  value  also  depends  on  t^.en,  which  is  the 
same  for  both  automata  since  it  is  pan  of  the  n+1  a  event  and  is  therefore  independent 
of  the  state  of  the  automata.  Consequently,  PhaseElect'  will  be  the  same  for  both 
automata. 

•  Total:  in  both  automata,  if  RunmngPhase=p  and  ExecMode(p)=normal,  Total"  will  be 
set  equal  to  Total+Valueip)^^^)-.  otherwise.  Total'  will  remain  unchanged  by  the 
n  +  1  u  event.  Since  by  inductive  hypothesis  RunntngPhase  and  ExecMode  are  the  same 
in  both  automata,  and  since  p  is  the  same  in  both  automata  since  it  is  pan  of  the  n+1  J( 
event  and  consequently  has  a  value  that  is  independent  of  the  state  of  the  automata,  the 
condition  under  which  Total'  will  be  updated  by  the  n+1  event  is  the  same  in  both 
automata.  Also,  since  Total  and  Value  are  the  same  in  both  automata  by  inductive 
hypothesis,  and  p  and  t  nt  are  both  part  of  the  n  +  1  Jt  event,  the  computed  value 
assigned  to  Total"  is  idenucal  in  both  automata. 

•  Value :  in  both  automata,  Value’ip)  is  unconditionally  set  to  v;  in  each  automaton,  p  and 
v  are  the  same  since  they  are  part  of  the  n+lsl  event  and  have  values  that  are 
independent  of  the  state  of  the  automaton.  Since  Value  had  been  the  same  in  both 
automata  after  n  events  were  accepted  and  since  both  automata  set  Value'{p)=v ,  Value' 
is  the  same  in  both. 

•  ExecClock:.  m  both  automata,  ExecClock’ip )  is  unconditionally  set  to  <fxprc,ed.  in  each 
automaton,  p  and  texperled  are  the  same  since  they  are  part  of  the  n+ls!  event  and  have 
values  that  are  independent  of  the  state  of  the  automatoa  Since  ExecClock  had  been 
the  same  in  both  automata  after  n  events  were  accepted  and  since  both  automata  set 
PdtecC lock' (p)=t expecud.  ExecClock'  is  the  same  in  both. 

•  ExecMode:  in  both  automata,  ExecMode'{p)  is  unconditionally  set  to  normal ;  in  each 
automaton,  p  is  the  same  since  it  is  pan  of  the  n+ls'  event  and  has  a  value  that  is 
independent  of  the  state  of  the  automaton.  Since  ExecMode  had  been  the  same  in  both 
automata  after  n  events  were  accepted  and  since  both  automata  set 
ExecMode'(p)=normal.  ExecMode'  is  the  same  in  both. 

•  ResumeTime:  in  both  automata,  ResumeTime  remains  unchanged. 


C-76 


Scheduling  Dependent  Real-Time  Activities 


Thus,  if  lbesa  accepts  any  of  these  event  types  as  the  event  in  a  history,  so  will  das.vnd.  and  the 
significant  state  components  of  each  automaton  will  be  the  same  at  that  point. 

Therefore,  by  induction,  dasa/vd,  and  hence  dasa  itself,  accepts  any  history  accepted  by  lbesa  under 
the  conditions  outlined  in  the  theorem  statement  Furthermore,  because  the  state  component  Total  will  be 
the  same  in  both  automata  after  accepting  a  history,  both  will  yield  the  same  value  for  any  history  that  they 
accept 

EndOfProof 


4.3.2. 4.  Proof:  With  Overloads,  dasa  May  Exceed  lbesa 

The  preceding  section  showed  that  the  dasa  Scheduling  Automaton  performed  well  when  there  were  no 
overloads.  In  this  section,  it  is  shown  that,  when  there  are  overloads,  the  dasa  Scheduling  Automaton  may 
accept  histones  that  yield  higher  values  for  the  application  than  any  history  that  may  be  accepted  by  the 
lbesa  Scehduling  Automaton.  The  reason  for  this  has  been  mentioned  previously  in  Sections  4.3.2. 1  and 
4. 3. 2. 2:  although  both  algorithms  use  similar  value  density  metrics,  they  construct  schedules  in  different 
ways,  potentially  resulting  in  situations  where  lbesa  sheds  some  phases  unnecessanly. 

Once  again,  for  the  sake  of  simplicity,  since  no  dependencies  are  involved,  the  dasaAD  Scheduling 
Automaton,  rather  than  the  dasa  Scheduling  Automaton,  is  use  in  the  following  proof.  The  result, 
however,  applies  to  the  dasa  Scheduling  Automaton  as  well. 

Theorem  3:  Consider  (1)  a  set  of  independent  activities  each  comprising  a  single  computational  phase 
that  is  charactenzcd  by  a  simple  time-value  function  —  a  step  function  with  a  positive  value  before  a 
designated  cntical  time  and  a  value  of  zero  after  that  time  (that  is,  each  phase  has  a  hard  deadline)  — 
where  (2)  there  are  insufficient  processor  cycles  to  allow  all  of  the  phases  to  meet  their  deadlines.  Given 
two  automata,  one  designated  Dasa/nd  that  accepts  histones  corresponding  to  schedules  generated  by  the 
Dasa  Scheduling  with  Dependencies  Algorithm  and  one  designated  lbesa  that  accepts  histories 
corresponding  to  schedules  generated  by  Locke’s  Best  Effort  Scheduling  Algonthm.  show  that  there  are 
situations  where  (1)  and  (2)  hold  and  dasaad  will  accept  a  history  with  a  greater  value  than  any  history 
LBESA  will  accept  involving  the  same  phases  and  the  same  scheduling  parameters  (time-value  functions  and 
required  computation  times). 

Proof.  This  proof  is  carried  out  by  constructing  an  example. 

Intuitively,  lbesa  constructs  a  complete  schedule  by  considering  each  phase  in  order  of  its  deadline, 
nearest  deadline  first  As  each  phase  is  considered,  an  estimate  is  performed  to  determine  whether  there  is 
an  overload  situation.  In  that  case,  it  discards  the  phases  with  the  lowest  value  densities  until  a  feasible 
schedule  is  obtained.  In  the  process,  it  may  discard  some  phases  unnecessarily.  dasaa’D  also  constructs  a 
schedule  from  scratch;  however,  it  begins  with  the  phase  having  the  greatest  value  density  and  considers 
subsequent  phases  in  decreasing  order  of  value  density.  Each  phase  is  included  in  the  schedule  in  order  of 
its  deadline  if  the  schedule  —  including  that  phase  —  is  feasible.  Since  this  approach  includes  as  many 
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high  value  density  phases  as  possible  and  only  discards  those  phases  that  cannot  be  added  to  the  schedule, 
rather  than  those  that  have  lower  value  densities  than  one  that  must  be  dtccorded.it  avoids  the  problem  that 
lbesa  encounters. 

An  example  of  dasa/vj  accepting  a  history  with  a  greater  value  than  lbesa  will  accept  can  be 
constructed  using  phases  with  the  following  parameters: 


Phase 

Deadline 

!  Required  , 

Computation  Time 

Value 

Pi 

2t. 

L+i 

I 

vl 

P- 

2‘. 

!  'a 

v2 

p3 

Vl 

I  1 

v3 

Let  ta>  1  and  vl,v2,  v3  >  0.  Also,  let  vl./(ra+l)>v2/fa>v3/(r  -1)  indicate  the  initial  relationship  of  the 
value  densities  of  the  three  phases.  pl,p2,  and  pS.  respectively.  Now  consider  the  following  history.  He. 


t,  =  o- 

request-phaset stept vl,  2t  ).  i 

P! 

u  =  0 

request-phasetstep(v2.  2ta),  ta) 

p2 

t3  =  0 

request-phase(step(v3,  2ta-l).  t a - 1) 

P? 

‘4  =  0* 

resume-phase(p3) 

S 

t5  =  V1 

request-phaset stept 0.  »'>,  01 

P? 

t6  =  <ta-ir 

resume -phase(pl) 

S 

‘7  =  2t, 

request-phasetstcptO.  «i.  0) 

Pi 

This  history  is  accepted  by  the  DAS  AND  automaton  and  has  a  value  of  vl+v3,  but  is  not  accepted  by  the 
lbesa  automaton  In  fact,  the  only  histones  that  lbesa  accepts  with  only  these  three  phases  and  the  same 
scheduling  parameters  have  value  vl  or  Lss.  The  following  secuons  demonstrate  each  of  these  facts  in 

turn. 

Dasaj.sd  Automaton  Accepts  History  H r  By  following  the  DaSand  automaton  through  the  slate 
changes  accompanying  the  acceptance  of  each  individual  event  in  the  history .  this  section  will  demonstrate 
that  history  Hj  is  accepted  by  DASANI).  For  reference,  the  DASA.ND  automaton  was  defined  in  Section 
4. 3. 2. 2. 

According  to  the  automaton  defimuon,  initially 
Total=0 

RunsungPhase=nullphase 

PhaseElcct=<normal.nuilphase> 

PhaseList=4 

The  following  labeled  steps  demonstrate  the  acceptance  of  each  event  in  history  //.  and  detail  the  changes 
in  state  component  values  that  accompany  each  event. 
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Value’ (p3)=step(v3.2ta-\ ) 
ExecClock'ipl  i=ra-l 
AbortC  lock’(p3)=0 
ExecMode’yp3  )=normal 
PhaseList'-{p\.p2  }o(p3  )  =  {p\.p2.p?  | 
PhaseElect'=SelectPhase({p\ ,p2p3 ) ) 


(since  texpecled>0) 


Evaluating  SelectP hase([p\ p2p3))  .  .. 


SeiectPhase({p\p2.pl\)  = 

pickone(mustfinishby(DLjirsl(pmplist)f  SCheduieJ'^P^'P‘''P^ 

where 

pmpltst  =tobescheduled(P sctleduie/[pl-p2p3  ) )) 


xMuiJlP  {pl^2) Mp3 })  (since  P UaslP,({p\p2p3  })~{p3 }) 

=  ,  p 

^  jcWuift/tpM)  . 

=  (since 

=  Pf'as.bl'(°^Pl  1) 

=  P feasible'  ^ 

=  (pi  ),if/ec2Jii>/e((pl  1) 

feasible{{p\ })  =  true,  .. 

tff(V/)[(/>t  (nt)  —> timerequiredbyimustfmishbyU ,{p  \ )))  S 


(since  /3,^„P\3(plp2})-(p2)) 


(since  ^.^vapiD-ipi)) 


For  t>r 


Of«l  ' 


mustfinishby(t,{p\  })  = 

0, 

(  <normaip>  I  p  € 


ifmui(co^p/efefr>(/.(pl 

mustcompleteby(t.{pl  ))!• 

otherwise 


)=o 


mustcompleteby  *,(pl  1) 

=  (p|[p€  (pi  )ADead/i>ie(p)<f]) 


=  0. 
tpu. 


Therefore 


if ;  <Dea  dlineip  1  )=2fa 
if  t  >  Deadlineip  1  >=2ta 


c-so 
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mustfinishbyi  t,  [p  1 } ) 

=  0. 

(  <normalp>  |pe  (pi  )  ). 

=  0. 

( <normalp  1  >  } , 


ift<2r 

a 

otherwise 
if  t<2t 

a 

otherwise  1 1  >  2t , ) 

a  ■ 


timerequiredby(mustftnishby(t,\p\ }))  = 

=  timerequiredby{0),  if«2ta 

timerequiredby{  ( <normal,p  1  > } ),  if  t  >  2:a 

=  0.  if  f<2ta 

ExecClockipl  )=/a+l,  if/>2ra 


Notice  that  for  f  >  f<VJfl<=0.  when  t  <  2ta  .  .  . 


nmerequiredby{mustfimshby(t,  (pi)  ))=0  < 
And  when  t>2t  ... 

a 


timerequiredby(musrfinishbyit,[p\  j  ))=/+!  <2ta<U-i  ^ent). 


Therefore  . 


as  required  for  feasibility 


as  required  for  feasibility 


feasible  (pi  ))=rnie  ->  P schedulJ  (pi }  >=(pl  1 
Continuing  .  .  . 


l> 

~  ^ feasible 

=  2D 

=  P feasible^  ^  )> 

To  evaluate  /’^li/,((plp>2()  . 


feasible{\p\,p2))  =  true,  iff (V/)[(f 

—inmerequiredby{mustftnishbyU,{p\p>2]))  <  U-te%en,)] 


mustfimskbyil.  (plp2))  = 

0,  if  mustcompleteby  (f,  (p  1  ,p2 )  )=0 

{ <normal,p>  |p€  muslcompletebyii .  (pl,p2})), 

otherwise 


mustcompletebyi  t.  ( p  1  ,p2 1 ) 

=  (p  |  [pe  [p\  j>2\b£)eadhneip)<t] ) 


=  0. 

lplp-1. 


if  t<Deadhneip  1  )=Deadhne<  p2)=2tj 
if  t  >  DeadhneipX  y=Deadline<p2)=2l 
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Therefore  .  . 


mustfinishbyU.  [p\  pi )) 

=  6. 

{<normalp>  | pe  [p\pi2\ 


if  t<2tj 
otherwise 


{ <normalp>  1  >,<norma!q>2> } , 


otherwise  (i>  2/  ) 


timerequiredby(mustfimshby(t,{p\p2\))  = 

=  ttmerequiredby(O),  iSt<2: 

timerequiredby({<normal.p\>.<normal,p2> J ). 

if  t  >  2t„ 

=  0.  if  t<2t 

a 

ExecClock(p\  )+ExecClock(p2)=2ta+ 1 ,  if  /  >  2ta 
Notice  that  for  t=2t„  .  .  . 

a 

timerequiredby(mustfimshby(t  ,{p\  p2\))~2t  a+\  >2.ta=(t-lri.en,) 
This  violates  the  requirement  for  feasibility,  therefore  .  .  . 


feasible!  [p\,p2]  )=false 

-*■ Pfe*sM'^P>2  1)  =  Pfeasiblet  )> 

=  (Pi  1 

->^W1P1-P2})  =  (P1) 

Continuing  .  .  . 

P  schedule/^1 'P2^ 

=  P feasible^ schedu,JiP^P2^{P3  D 

=  P feasible'  ( P 1 ) ^ ! P^ ) ) 

=  Pftas,blMP1^)) 

To  evaluate  Pf*uibleUPl<PW  ■■■ 


(since  PleaslPX({p\p2))={p2}) 
(as  shown  above) 
(since  P  schedule/  (P'-P2)  )=P feasible^ (P 1  -P2 1 » 


(as  shown  above) 


feastble([p  \  .pi  ))  =  true,  iff  (Vt)[(/>tfvr(lf) 


>timerequtredby(mustfinishby(t,[p\p>2>)))  <  (t-tfvrn()] 


For  t>t 
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mustfinishby(t,\p\pS\)  - 

0,  if  mustcompleteby{t,\p\ ,pS }  )=0 

( <normal,p>  \p£  mustcompleteby(t.{plpS})}, 

otherwise 


mustcompleteby(t,{p\  ,p3 }) 

=  {p\[p£  {plpS  \cJDeadline(p)St]} 

=  6. 

l/>3}. 


if  t<Deadline(pS)=2t  a-\ 
if Deadline[pS)=2t a-l  <1 
<  Deadlineipl  )=2  ta 
if  t  >  Deadlineip  1  )=2  / 


Therefore  .  . 


mustfimshby(t.[p\  pS )) 

=  0, 

{ <normalp>  |  p  £  (p 3 1 }, 
[<normalp>  j  p  £  {plp3}l. 


dt<2ta-\ 

i{2ta-l<t<2ta 

\l2t<t 


\<normalpS>) . 

( <normalp\>,<normalpS>\ 


\it<2.t-\ 
\l2t-\<t<2ta 
if  2  t<t 


timerequiredby(mustfimshby(t,{plp3  j ))  = 

=  timerequiredby(O),  dt<2ta-l 

timerequiredby{{<normalpS>)),  i(2ta-\  <t<2ta 

timerequiredby(  ( <normalp  1  >,<normalpS>  ) ), 


d2t  <t 
a 


=  o, 

ExecClock(p3)=ta~\.  if2:fl-l 

ExecClock(p\)+ExecClockipS)=-2t  a,  if  2ta  <t 


ift<2ta-l 

i(2t-\<i<2ta 
a  a 


Notice  that  for  t  >  when  t  <  2tj- 1  .  . . 


timerequiredby(mustfinishby(t,\p\pS }  ))=0  < 


as  required  for  feasibility 


When  2f -1  <«2f  .  . 


timerequiredby(mustfinishby{t,\p\  pS\))-=4  a-\  <  2ta-\  <( t-tevent ). 


as  required  for  feasibility 


And  when  t>2t„ 


timerequiredby{mustfinishby(t.\p\  pS)))=2ta<(t-t  rieru). 


as  required  for  feasibility 


Therefore  .  . 


feasiblef  {p\pS})=true 

/>2,p31)={pl.p3| 


Scheduling  Dependent  Real-Time  Activities 


C-83 


So  p schedule /  (pi  .p2,p3 1).  the  set  of  phases  that  can 
feasibly  be  executed  so  that  each  will  meet  its  deadline  while  contributing 
the  maximum  value  to  the  system  for  the  investment  01  a  given  amount  of 
ume,  has  now  been  determined.  Next,  the  individual  phase  from  this  set 
that  will  be  executed  first  must  be  determined  .  .  . 

pmplist  =  tobeschedulediP  schfdulJ{p\p2p3})) 

=  tobescheduled{[p\  ,p3 } ) 

=  { <normal,p\>,<normalp2>\ 

DLprst(pmplist)  =  DLj-irsl({<nornuilp\>,<jiormalp3>}) 

=  2ta~l 

mustfintshby(DLfirl'(pmplist)J,sch'dule/ {plp2p3 })) 

=  mustfimshby(2ta-l,{p\  p2 1) 

=  { <normal,p>  jp£  mustcompleieby{2t  -1  ,  (pi ,p3))} 

( assuming  mustcompleteby(2ta-\,{p\p3})*6) 
=  [<normal,p>\pe  {p\p3  \rDeadline{p)  < 2ra— 1 ) 

=  {<normal,p>  \  p  €  (p3}j  {note  that  mustcompleteby{2ta-\,\p\p3))*- to) 

-  { <normal,p3> } 


Finally  .  .  . 

PhaseElect'  =  SelectPhase{  (pi  ,p2,p3  1) 

=  pickone{mustfinishby{DLfirst{pmplist)J> schtduie/  (pi  ,p2,p3 ) ))) 
=  pickone{  { <normalp2>  j ) 

=  <normal.p2> 


Event  4;  t4  =  0+ 


resume-phase(p3) 


event  parameters: 


'even,  =  '4  = 


precondition: 


P  =P3 


(RunningPhase=nullphase)/\{Phase(PhaseElect)=p2) 

MPhasei PhaseElect)*  nullphase)/\(Mode{PhaseEtecD=normal) 


(RunningPhase-=nullphase)MPhasei<normal,p2>)=p3) 

r\{Phase(<normalp2>)*nullphase)/\{Mode(<normal,p2>)-=normal) 


true 


(so  the  event  is  accepted) 


postconditions: 

ResumeTime'lp  3i=0* 

RunningPhase'  =Phase(PhaseElect)=Phase{<normal,p2>)=p2 
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Event  5:  t5  =  ta- 1  request-phase(step(0, »).  0)  p3 


event  parameters: 

1  event  ~  lS  ~ 

v  =  step(0,°°) 

t expected  ~  ® 

P  =P3 

precondition:  true  (so  the  event  is  accepted) 


postconditions: 

Totaf=0+Value(p3)(t  -1)  (since  RunningPhase=p3AEjcecMode(p3)=norma[) 

=  step(v32ta-  l)(fa-l) 

=  v3 

Value'(p3)=step(  0,°°) 

ExecC  lock'(p3)=0 
AbonClock'  (p3)=0 
ExecMode'(p3)=normal 

PhaseList'={p\.p2.p3\-[p3)  =  [plp2)  ( since  texpecled=0) 

PhaseElect'=SelectPhase(  (p  1  ,p2 ) ) 

RunningPhase’=nullphase  ( since  p3=RunningPhase) 

Evaluating  SelectPhase((p  lp2})  ... 

Se!ectPhase([pl  ,p2})  = 

pickone(mustfinishby(DLfirsl(pmplist)J,schtduleJ,\p\ ,p2 ) ))). 

where 

pmplist  =tobescheduled(P  schedule/  {p  1  ,p2 ) )) 

PtOte^PW)  ~ 

Pfeastble(FscH*JulJlPl  » Mp2})  <«'"«  PleastP^P{'P 2})={p2}> 

P scheduia/-^Pl  D 

=  P feasible^  schedule/*^'  >>  (s,nCe  ^  >  )=(/> 1  D 

sPJeas,ble^Pl» 

=  Pfeastble^P^^ 

=  (pi },  xifeasible([p\ )) 

feast ble( (pi })  =  true, 

'd[(Vt){(t>trven[)-*timerequiredby(mustfimshby(t.\p  \ }))  <  (f-revtnt)] 


As  before,  for  t  > <tYenl=ta-l 
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mustfmishby{t,{p\ })  = 

0,  if  musicompleteb\U.{pl ) )=0 

|  <normal,p>  |  pe  mustcompleteby(t,{p\  ))}, 

otherwise 

mustcompleteby(t,\p\  ]) 

=  {p  |  [pe  [p  1  }cDeadline{p)<t}} 

=  6,  if  t<Deadlme(p  1  )=2  ta 

{pi],  i(t>Deadline(p\)=2ta 

Therefore  .  . . 

mustfinishbyft,{p\ )) 

=  6,  ift<2ta 

{ <normalp>  |  p  e  {pi)].  otherwise 

=  6,  if^<2/fl 

{</wmu/1pl>),  otherwise  (/>  2/fl) 

timerequiredby{mustfinishby(t,(p\ )))  = 

=  timerequiredby(O),  if  l<2ta 

timerequiredby(  { <normal,p  1  > } ),  ift>2ta 

=  0,  ift<2/a 

ExecClock{p\)=ca+\ ,  ift^2ta 

Notice  that  for/Sr^^s^-l.  when  t  <  2ta 

timerequi  redbyf  mustfini  shby(t ,  {p  1  ] )  )=0  <  ( 

And  when  /  >  2ra  ... 

timerequiredby(mustfinishby(t,{p\  ]))=fa+l  ~(f~reveM)< 

Therefore  .  .  . 

/easi  Me(  {p  1 )  )=true  -*  pschrtiulJ  (P 1 1  )=  (P 1 1 
Continuing  . 

P  scheduled  i  P 1  1 ) 

=  1  M?2 1  >  (ai  shown  above) 

“  *>«».•«/ U^MP2)) 

=  r,tasMeWj>2)) 

feasible({p\,p2})  =  true,  iff  (Vt)[(/>teve^,) 

—>timerequiredby(mustfmis!:by(t,[p\p>2}))  <  (/-frvrn<)] 

As  before,  for  t  >  trx,enl  .  . . 


as  required  for  feasibility 


as  required  for  feasibility 
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mustfinishby(t,[plp2})  = 

6.  if  mustcompletebyi  t,  {p  1  ,p2 )  )=0 

{<normal.p>  |pe  mustcompleteby(t%{pl  p2})} , 

otherwise 


mustcompletebyi  t.{p\.p2\) 

=  {p  |  [p€  [pi p2) ADeadlineip) ^ t]) 

=  6. 

{pl^2(, 


Therefore 


if  t<Deadline{p\)=Deadline(p2)=2ta 
if  t  >  Deadlineip\ )=D eadline(p2)=2t 


mustfmishbyit ,  {p  1  ,p2 ) ) 

=  0. 

[<normalp>\  pS  [p\p2)\, 

=  6, 

{ <norm<3/,pl>,</i0muii’,p2>). 


if  r<2/_ 

<3 

otherwise 

.fr<2ra 

otherwise  (t>2t ) 


timerequiredby(mustfinishby(t,  (p  1  p2 ) ))  = 

=  timerequiredby(t)),  if/<2/a 

ti merequiredbyi  { <normal,p  1  >,<normal.p2> } ), 

if  r  >  2ra 

=  0,  if  t<2ta 

ExecClock(p\)+ExecClockip2)=2ta+\,  iff  >  2fa 

Notice  that  for  f=2fa  .  .  . 

timerequiredby{mustfinishby{t.  (p  1  p2 }  ))=2r  0+ 1  >  ffl+l  =(f-f,v,n,) 
This  violates  the  requirement  for  feasibility,  therefore  .  .  . 


feast blei  (pl,p2  }  )=false 

-*  Pf«u.hl<(  Ip1/’2))  =  Pfeasd,tA  \P' 1 ) ) 
=  (pl) 

-*PScH"tulJ{PX’P2»  =  \P^ 


( since  p  w/>v(IP1P2))=(P2)) 
(as  shown  above) 

(SinCe  P  scheduled^  iP’P2)  >P t? 1  P2  » » 


Once  again,  the  set  of  phases  that  can  feasibly  be  placed  in  a  schedule 
based  on  current  knowledge  has  been  determined.  Now  a  single  phase  must  be 
selected  to  execute  first  .  ,  . 
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pmplist  =  tobeschedulediP ichedulJ  [p\p2\  )) 
=  tobescheduledi  [p  1 )t 
=  {<normal,pl>} 


DLfirs,{pmplist )  =  DL}-trsl{[<normalp>  1>)) 


mustfimshby( DLfirs,(pmphst).P  schedulJ  [p  1  p2 } )) 

=  mustfimshby(2t  a,{p\  |) 

=  [<normal,p>  |/>€  mustcompleteby(2t  a.[p\ })) 

(assuming  mustcompleteby(ha,{p\  ) )  *  6) 
=  {<normal,p>  |p€  [q\[qe  \p\  \rsDeadline(q)<2ta\) ) 

=  ( <normal,p>  |  pe  [p\  | }  (note  that  mustcompleteby(2t  a,(p\  ))*0) 

=  [<normal.p  1>} 


Finally  .  .  . 

PhaseElect'  =  SelectPhase( \p\ ,p2 ) ) 

=  picltone(musifirushby(DLfirsl(pmplist)J’schtdule/{pl.p2 ) ))) 
=  pickone([<normalp\> }) 

=  <normal,p\> 


Evem  6:  t6  =  1  )*  resume-phase(pl )  S 


event  parameters: 

'  6  =  V1)* 

P  -P't 


precondition: 

(RunningPhase=nullphase)/\(Phase(PhaseElect)=p\) 

MPhase{PhaseElect)*nullphase)/\(Mode(PhaseElect)=normal) 


(RunningPhase=nullphase)/\(Phase(<nornuil.pl>)=pl) 

/\(Phase(<normalj)\>)*  nullphase)/v(Mode(<normal,p\>)=normal) 


true 


(so  the  event  is  accepted) 


postconditions: 

ResumeTime'ip  1  1 V 

RunmngPhase'=Phase(PhaseElect)=Phase(<normahp\>)=p\ 


Event  7 :  t7  =  2ta  request-phase(step(0. «»),  0)  pi 

event  parameters: 
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t 


=  f,  =  2t 
c\ent  a 

■■  =  slept  O.oo) 


Expected  ® 

P=P  1 


precondition:  true  (so  the  event  is  accepted) 


postconditions: 

Totaf=v3+Value(pl)(2ta)  ( since  RunmngPhase-p\  cExecModeipl  )-narmal) 

=  vS+sre/Hvl^Xl^) 

=  v3+vl 

Value' (p  1  )=step(  0.“) 

ExecC  lock'ip  1  )=0 
AbortClock'(p  1  )=0 
ExecMode'(p\  )=normal 

PhaseList'={p\.p2)-{p\  }  =  \p2\  (since  t expecled=0) 

PhaseElect'=SelectPhase(  {pi ) ) 

RunningPhase  =nullphase  (since  pl=RunnmgPhase) 


Therefore,  the  history  is  accepted  by  the  dasa/nd  automaton  and  has  a  total  value  of  Totals l+v3. 

lbesa  Automaton  Does  Sot  Accept  History  H  r  The  first  two  events  are  accepted  in  the  same  way  as 
they  were  for  dasa/nd.  Also,  all  of  the  state  components,  with  the  possible  exception  of  'PhaseElect.'  are 
the  same  for  both  automata  after  the  first  two  events.  After  that.  LBESA  behaves  differently  than  dasa/ND. 
The  following  development  shows  the  behavior  of  LBESA  in  detail.  (Refer  to  Section  4.3.2. 1  for  the 
definition  of  the  lbesa  automaton.) 

According  to  the  automaton  definition,  initially: 

Totals  0 

RutmtngPhase=nullphase 

PhaseElect=<normal,nullphase> 

PhaseList=6 

The  following  labeled  steps  demonstrate  the  acceptance  of  the  first  few  events  in  history'  Hj  and  detail  the 
changes  in  state  component  values  that  accompany  each  event. 


Event  1:  tj  =  0‘  request-phase(step(vl,  2ta),  ta-*- 1 )  pi  \ 

event  parameters. 

'™,  =  'i=0- 

v  =  st  ep\v\.2ia) 

Expected  ~~  ^ 

P  =P  1 

precondition:  true  (so  the  event  is  accepted) 

postconditions: 
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Value'(p\)=step(  vl  2ta) 
ExecClock'ip  1  )=ta+ 1 
AbortClock' (p\  )=0 
LxecMode'ip  1  )~normal 
PhaseList'=Ou{p\  }  =  {pl  ( 
PhaseElect’-SelectPhasei  (pi]) 


{s,nce  1  expect 


Event  2:  t,  =  O'  request-phase(step(v2.  2ta).  ta) 


event  parameters. 


'even,  =  f2  =  °' 

v  =  step{\22ta 

* expected  ~  *  a 

p -p 2 


precondition:  true 


(so  the  event  is  accepted) 


postconditions: 


Value'(p2)=step(v22ta) 

ElxecC  lock'{p2)=t  a 
AbortClock’  (p2)=0 
ExecMode'{p2)=norma  1 
PhaseList’=[pl  )tu{p2  )={pl  p2 ) 
PhaseElect'=SelectPhase({pl.p2\) 


ince  'expect 


Event  3 :  t3  =  0 


request-phase(step(v3,  2ta-l),  t4-l) 


event  parameters: 


r  =  t-,  =  0 

event  d 

v  =  rtep(  v3,2/a-l ) 

l  expected  ^ 

P  =p3 


precondition:  true 


(so  the  event  is  accepted) 


postconditions: 


Value'(p3)=step{v32ta-\ ) 
ExecClock'{p3  )=ta~  1 
AbortClock'  (p3)=0 
ExecMode'{p3)=normal 
PhaseList'=[p\,p2)vj{p3  )  =  (pl,p2,p3 ) 
PhaseElecT=SelectPhase(\p\,p2p3}) 


(S,nCe  < expected >°> 


Evaluating  SelectPhasei\p\ p>2p3 ))  . 
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Select  Phase({p\,p2.p3\)  = 

pickone(mustfinishby(DLfirsl{pmplist )-P  scheduit/ \p  1  -P^.pl  1 ))). 

where 

pmphst  =tobescheduled(P schrduleJ  \p\  ,p2p3 } )) 

P scheduled-  (P 1  p2.pl } )  = 

'  *  Pfeanh/P  schedule/^1 -P3^P2^  {since  P  tastDL{[p\ p2p3\)=[p2\) 

P  schedule/^1 

Pfe*»bie(PscheduleJ-{P3^Pl  1)  {sinCe  PuuDlW&WpI  D 

P schedule/ ^P3  *  ) 

=  P feasible^ schedule/^P^  ^  P las.DL^  1W  » 

=  PfeasMe^Pi  » 

=  Pfeas,bte^P3^ 

=  [p3], if feasible{{p3}) 

feasible ( (p3})  =  true, 

iff  ( Vf)((/  >  teveru)  -*  timerequiredby(mustfinishby(t,[pl> ) ))  <  (t-t^,enl)] 


mustfimshby{t.{p3 1 )  = 

(5,  if  mustcompleteby(t. [p3  ))=0 

( <normal,p>  |  pe  mustcompleteby{t.{p3\)). 


music ompleteby  ( /,  lp3 }) 

=  (p\  [pe  ( p3)rd)eadline{p)<t ]) 

=  6, 

(p3|. 

Therefore  .  .  . 

mustfinishbyit.  (p3 } ) 

=  6, 

( <normal  p>  |  p  6  {/?3 } } . 

=  6, 

{ <normalp3>\ , 

timerequiredby(mustfimshby(t.\p3\))  = 

=  timerequiredby{C>), 
timerequiredby{  ( <normal.p3>} ), 

=  0, 

ExecC  lock(p3  )=ta- 1 . 

Notice  that  for  t  >  tevenl= 0,  when  t  <  2t,- 1 

timerequiredby(mustfinishby(t,{p3}))=Q<i(t-trvenl 


otherwise 


i  f  t<D  eadlineip3  )=2ra- 1 
if  t  >  Deadline{p3  )=2  iQ- 1 


ifr<2/  -1 

O 

otherwise 

ifr<2ra-l 

otherwise  (f>2ra-l) 

if«2ra-l 

,ft>2ra-l 

ifr<2/a-I 

.fr>2ra-l 


as  required  for  feasibUity 


Arid  when  t>2t-\  .  .  . 
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tmerequiredby(mustfmishby(i,{p3)))=ta-\  <(t-t^.enl). 


as  required  for  feasibility 


Therefore 


feasible ( ( p3})=true  -*  P  schtduiA  })-{/>3 } 
Continuing  .  .  . 


=  jP feasible^ scheduled^  (^3  }  )<_J  [p  1  ) ) 

=  f,ftas>biAPl-P2 D 


feasible(\pl.p3})  =  true,  iff  (V?)[(/>t^lfn() 

— >ttmerequiredby(mustfinishby{t,{p\j)3 )))  £  (t-twn,)] 


{as  shown  above) 


For  t>t 


event  '  ' 


mustfinishbyUdP^  1)  = 

0. 

{ <normal,p>  |  p€ 


if  mustcompleteby{t.{p\ ,p3 }  )=6 
mustcompleteby(t,[p\,p3  ()), 

otherwise 


mustcompleteby{t.{p\  .p3 } ) 

=  Ip  |  [pe  |pl,p3 }  wDeadline(p)^t) ) 


=  0. 

Ip3 ), 

{plj>3}. 


if  t<Dead!ine{p3)=2ia-\ 
if  Deadhne{p3)=2t a-\  <t 
<Deadline(p\)=2ta 
if  l  >  Deadhne{p  1  )=2ta 


Therefore  .  .  . 


mustfinishby(t,{p\p>3  1 ) 

=  0, 

{ <normalp>  |  p  £  {p3  ) ) . 
\<normalp>  |p€  }pl,p3}). 


if«2ta-l 

i(2ta-l<t<2ta 

if2tfl<t 


=  0, 

( <normalp  3> } . 

(<normalp\>.<normat4>3>\. 


ift<2ta-l 
if 2tfl-l  <t<2ta 
d2,a<t 


timerequiredby(mustfinishby{t.  [p  1  p3 } ))  = 

=  timerequiredbyib),  ift<2t0-l 

timerequiredby{{<normal,p3> ))■  if2/a-l  £t<2/a 

timerequiredby{\<normal,pl>,<normal,p3>\), 

if2fa<r 


=  0,  ift<2ta-l 

ExecClockip3)=ta-\ .  if2ra-l  <t<2ta 

ExecClocLip  1  )+ExecClock(p3  )=2ta,  if  2ra  £  r 
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Notice  that  for  t  >  t  „„  =0.  when  t  <  2t  -1  ... 

event  a 

timerequiredby(mustfinishby(t.[p\p3  )))=0<(r— as  required  for  feasibility 
When  It- -1  </<2r  .  .  . 

a  a 

timerequiredby(mustfimshby{t,[p\p3}))=ta-\  < 2/^—1  ^(t-tevenl). 

as  required  for  feasibility 


And  when  t  >  2ta  ... 

timerequiredby(mustfinishby(t.{p  1  p3  )  ))=2 ta  < 

as  required  for  feasibility 

Therefore  .  .  . 


feasible(  {pl.p3}  )=true 

-*  pf«is>bt'(  Ip  1  p3 }  )={p  1  ,p3 ) 

schedule/ iPl-P3^Pl’P3^ 

Continuing  .  .  . 


P  sctudulJ-W'P2^ 

=  ^own  ^ove) 

=  PfeasMe^'P^P2^ 

To  evaluate  Pfeasible(\P^-P2-P^\)  ■■■ 


feasible([p\,p2p3\)  =  true,  iff (Vr)[(r 

—>umerequiredby(mustfinishby(t.{plp2p3}))  S  (r-rrvf„,'>] 


Forr>r 


event 


mustfinishby(t.{plp2p3\)  = 

<5,  if  mustcompleteby(t,{p  \  ,p2,p3  )  )=0 

( <normal.p>  \  p  6  mustcompleteby(t.{p\  .p2.p3 ))}, 

otherwise 


mu stcompleteby(t. \p\ ,p2.p3 1 ) 

=  (p|  [pe  {p\p2p3  } ej)eadline(p)  <r] ) 


=  d, 
lp3|. 

[p \p2p3]. 


if  t<Deadhnei  p3  )=2  tQ- 1 
\{ Deadline{p3)=2ta-\  <t 
<Deadline{p\)=2ta 
if  t  > Deadlineipl  )=2 ta 


Tiierefore 
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mustfmishby(t,[p\ .p2p3 } ) 

=  0, 

( <normalp>  |  p  6  (p3)|. 
[<normalp>  \pe  (pl.p2.p31! 


i{2ta-l<t<2ta 
if2  i<t 


=  0.  ift<2?a-l 

{<norma!q ?3>).  if  2ta-l  <  t  <  2ia 

{<norma!q>l>.<norma!p2>,<normalp3>}, 

if  2  t<t 


timerequiredby(mustfmishby(t,{p\,p2p>'i )))  = 

=  timerequiredby(t>),  if  t<2t~] 

timerequiredbyi  (  <normal.p3>  i ).  if2ra-l  <t<2ta 

timerequiredbd ( <normal,p l >.<normal.p2>.<normal.p3>} ). 

if  2  t<t 


=  0,  if  t<2ta~\ 

£jtec£/odt(p3)=ra-l.  if2ra-l  <t<2ta 

ExecClock{pl)*-ExecCloclc{p2)+ExecClock{p3)=3t  , 


if2/a<r 


Notice  that  for  r=2r,  . .  . 


timerequiredby{mustfinishby{t.[p\  p2p3)))=St  a>2t  a={t-t  ^.en^) 
This  violates  the  requirement  for  feasibility,  therefore  .  .  . 

feasible ( (pl,p2,p3 }  )=false 

Pfea„blMPl  T>2p  3  )  )=Pftaslhle{  ipUp2}) 


(since  PleaslPVi[plp2p3})=(p 3D 


To  evaluate  P feasible^  P^<P2)) 


feasible({p\.p2))  =  true.  ifffV/Xf/Sr^,) 

— >  timerequiredby(mustfinishbyU.[p  \  p2}))  <  (f-r  Bf)] 


Forr>r 


musf/i/ui/iby(t.{pl^21)  = 

6,  if  mustcompletcbv(t.{p\  ,p2 )  )=0 

{ <normal.p>  |pe  mustcompletebyit  .{p\  ,p2 ) ) ) , 

otherwise 


mustcompletebyit, {p\  ,p2 ) ) 

=  I  [Pe  {pl^>2)A£>ead/me(p)<f]| 

=  6, 

(plp2). 

Therefore  .  .  . 


if  i<Deadline(p  1  )=Deadline(p2)=2tg 
if  1 2  Deadhne[p\  ]=Deadl\ne(p2)-2j a 
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mustfinishby{t.{p\  q>2 ) ) 

=  0.  iff<2r 

a 

[<normalp» |pe  (pl,p2}  j.  otherwise 


=  0.  ifr<2f 

a 

{ <norrru2!j?1  >,<normalp  2> ) ,  otherwise  ( t  >  2ta ) 


timerequiredby(musifinishby(t.[p\j)2 }))  = 

=  timerequiredby(O),  iff<2fo 

nmerequiredb\([<Jiormal.p\>.<normal.p2>}), 

iff  >2/ 

<2 


-  0.  iff<2r 

a 

ExecClock{p\)+ExecCloclc(p2)=2ta+l,  iff > 2ta 


Notice  that  for  t-2t„  .  .  . 

a 


timerequiredbyimustfinishby(.t,{plq?2}))~2ta+ 1  >  2ffl=(f-f  W(U) 
This  violates  the  requirement  for  feasibility,  therefore  .  . 


feasible ( {p  1  ,p2 1  )=false 

-  W 1  1  iP1 ) )  («■«"  !pl^2)  )=(p2 ) ) 

To  evaluate 


feasible ( (pi  j)  =  true. 

i{{(Vt)[{i>t^.tnl)-*timerequiredby(mustfinishbyit,{p\ )))  S  (f-f,VMl)] 


For  f  > t 


tvenl  ' 


mustfinishby(t.{p  \  ])  = 

Q.  i(mustcompletebyit,\p\))=0 

( <normal.p>  |  pe  mustcompleteby{t.{p\ })}. 

otherwise 


mustcomp!eteby(t.[p\ }) 

=  (p|  (pe  (pi } rDeadline(p)<t) } 

=  0,  \f  t<Deadline{pl  )=2ta 

(pi),  i{t>Deadline(p\)=2ta 

Therefore  .  .  . 
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mustfinishbx(t.{p\  I.) 

=  0.  if'<2  ta 

[<normal.p>  \  p €  {pi } ) .  otherwise 

=  0,  if'<2/a 

[<norma!q>l>],  otherwise  (t>2ta) 

nmerequiredby(mustfmishby(t.{p\  ())  = 

=  nmerequiredby(O),  ift<2ra 

timerequiredby(  { <normal.p  1  > ) ),  i(t>2ta 


=  0, 

ExecC lockip  1  )=ta+ 1 .  if  <  -  2ra 


Notice  that  for  t  >  tnen  =0,  when  t  <  2ta  ... 

timerequiredby(musrfinishby(t,{pl ) ))=0  < fw^).  as  required  for  feasibility 

And  when  />2r  ... 

a 

timerequiredby(mustfinishby(t.{pl  |))=fa+l  -2la-(l~leyeni^’ 

as  required  for  feasibility 

Therefore  .  . . 


feasible(  (pi)  )=true  — >  V^(lpll)=(pl) 
Putung  this  together  .  . . 


Ps cMulJ  {Pl-P2-P 3D  =  (P 1  -P2-P3 1 ) 

(since  feasible(  (p  1  p>2p>3 )  )=falseeJ>, tas,p\{  [p  1  ^2^>3 } )-  (p3 ) ) 


=  (pi) 


(since  feasible(  (pi  q>2 )  )=falseeJ’ ieaslP^{  {plq>2 } )={p2 1  > 

(as  shown  above) 


At  this  point,  the  set  of  phases  that  can  be  feasibly  executed  has  been 
determuic^.  Now  to  decide  which  phase  to  be  executed  first  ... 


pmplist  =  tobescheduled(PschrjuIe/\p)<p2p>}>})) 

=  tobesrheduled ( (pi  )) 

=  [<normal,p  1>) 

DLfirJomphst)  =  DLrrsl(  |  <normn/pl> ) ) 

=  2', 

mustfinishby(DLprJpmplist).Pschedul'd(  jpl  p2,p3 ))) 

-  mustfmishby(2ta,(p  \ )) 

=  {<normal,p>\p£  musicompleteby(2ta,{pl))) 

( assuming  mustrompIeieby(2la,{p\  ))*$) 
=  {<norma!,p>\pe  (p|(<?G  [p\)ADead!ine(q)<2ta])) 

=  [<normal.p>  \  p  G  (pi)}  (note  that  musicompleteby(2ia,{p\))*i>) 

=  (<norma/.pl>) 
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Finally  .  .  . 

PhaseElecT  -  SelectPhasci  {p\ .pl.p'S ) ) 

=  pickonelmustfinishbyiDL^ipmplisttJ3 scheauie/\pl  .p2.pl]  ))> 
=  pickone(\<normalp\>\) 

-  <normal.p\> 


Event  4:  t4  =  0*  resume-phase(p3)  S! 

_ I 

event  parameters: 


*  event  ^4 


0" 


P  =p3 


precondition: 

(RunningPhase=nullphase)MPhase(PhaseElect)=p'i) 

/ \(Phase{PhaseElect)*nullphase)MMode(PhaseElect)=normal ) 


(RunningPhase=nullphase)MPhase(<normal.p\>)=p?>) 

MPhase(<normalp>\>)  nullphase)/\{Mode(<normal.p\>)=normal) 


false,  (since  Phase(<normalp\>^=p\  *  p3) 

Since  the  precondition  is  not  satisfied,  the  event  cannot  be  accepted. 


Therefore,  history  H t  is  not  accepted  by  the  LBESA  automaton. 

LBESA  cannot  accept  any  history  that  begins  with  Events  (l)-(3)  and  that  has  only  those  three  phases, 
with  the  already  specified  time-value  functions  and  computation  time  requirements,  that  will  yield  a  total 
value  greater  than  v  1 

This  proof  will  be  earned  out  by  identifying  all  of  the  histones  that  LBESA  can  accept  under  these 
circumstances.  The  total  value  resulting  from  each  of  these  histones  will  then  be  examined  to  demonstrate 
that  none  is  greater  than  vl. 

To  begin  to  identify  the  histones  that  are  accepted  by  L3F-:sa,  notice  that,  given  Events  ( 1  M3),  lblsa  will 
behave  exactly  as  desenbed  in  the  preceding  section.  After  accepting  Event  (3),  the  third  event  in  this 
sequence,  the  only  events  whose  preconditions  are  satisfied  are: 

1.  any  'request-phase’ 

2.  'resume-phase(pl)’ 

Examine  the  first  possibility  —  any  ’request-phase’  event  —  more  closely  Let  ps  denote  the  phase 
onginating  a  'request  phase'  event.  If  p^  i  {pi.  p2,  p3),  then  p^  is  a  new  phase.  But  this  violates  the 
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assertion  that  the  only  histories  being  considered  consist  solely  of  events  associated  with  phases  pi,  p2,  and 
p3.  Therefore.  px  must  be  a  member  of  fpl .  p2.  p3). 

Also,  notice  that  after  accepting  Events  (l)-(3).  RunnmgPhase=nullphasc.  which  is  not  a  member  of  (pi, 
p2,  p3).  Consequently,  the  postcondiuons  of  a  'request-phase(vx.  tx)  px'  rent  are: 

Value'(px)=vx 

ExecClock’(pi)=tx 

AbortClock'(px)=0 

ExecMode'ip  )=normal 

PhaseList'=PhaseList\j  {px\  or  Phase  List- ( px ) 

Phase  Elect' =SelectPhase(  Phase  List') 


Notice  that  these  postconditions  serve  only  to  alter  or  reiterate  the  scheduling  parameters  of  the  already 
defined  phases  (possibly  removing  one  of  the  phases  from  consideration  from  scheduling  at  the  same  time 
and  potentially  selecting  a  new  PhaseElect  to  reflect  these  changes).  If  the  scheduling  parameters  are 
altered,  this  violates  the  assertion  that  the  automaton  will  consider  only  the  time-value  functions  and 
expected  computation  times  already  specified  for  the  three  phases  by  the  first  three  events  Consequently, 
the  only  ’request-phase’  events  that  lbesa  can  accept  at  this  point  reiterate  the  scheduling  parameters  for 
px  6  (pi,  j .2,  p3).  (Hereafter,  ’request-phase'  events  that  serve  to  reiterate  previously  defined  scheduling 
parameters  may  be  referred  to  as  reiterative  'request-phase'  r-ents.)  Furthermore,  notice  that  although 
such  ’request-phase’  events  do  not  alter  the  scheduling  parameters  for  a  phase  —  they  merely  reiterate 
them  —  there  is  a  potential  effect  of  these  events  on  the  automaton  state  component  PhaseElect.  which  is 
set  equal  to  SelectPhase(Phas',List’)  as  a  postcondition  of  each  ’request-phase’  event.  The  function 
SelectPhaseO  is  dependent  on  t  nt.  which  increases  during  the  course  of  any  history. 

To  examine  the  effect  of  a  ’request-phase’  on  PhaseElect  consider  first  the  effect  on  the  value  of 
p  schedule/ -P2,p3 1)  as  a  function  of  tfvenr  Of  course,  trrni>  0  since  only  legal  histones  are  under 
consideration  here,  and  the  third  event  occurred  at  time  =0  With  that  in  mind,  expand  the  value  of 

P schedule/ 1  Pl'P2’P3  35  foUowS: 

PscheduJe/lP1’P2-P3))  =  P/eas,hle<PsrheJule/IPlP3)}^tP2l}  (since  P.^Hpl  ))=(p2)) 

=  P feasible^  P  feasible^  P  schedule/  I  ( P 2  I '  P  lasio/  (P1  -P3  1  Hpl  D 

=  Pfeauble{ Pfe«s,ble( P feasMe( P schedule/ 0 > ^ < P 3  I  Mp  1  IMP-  i )  (Since  P  hstDL(lpl  1  )=(/*  )) 

=  P feasible* Pfeas,ble( Pfe*s,ble( «M/>3  |  M/>1  )  M/>2  | ) 

=  P feas,ble(P feasible^ ' feasible^P^  )  )s— ' { /?  1  Ih-^i p2  1  ) 

PfeasibuUPW‘ 

(p3),  iffeasible({p’i }.) 

ti,  otherwise 


Several  feasibility  conditions  tike  this  will  have  to  be  evaluated  in  the  following  section  of  the  proof. 
Therefore,  a  general  result  will  be  denved  here  that  can  be  applied  to  any  of  the  simple  cases  that  follow. 
Consider  a  phase  p  with  automaton  state  components: 
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Value(p)  =  step(\\tDL) 

ExecClockip)  =  t  required 
AbortClocldp)  =  0 
ExecModeip)  =  normal 

Notice  that  pi,  p2,  and  p3  all  satisfy  this  profile  at  this  point  in  the  automaton's  examination  of  any 
history  that  it  accepts.  Then  .  .  . 

feasible(\p\ )  =  true,  iff  (V  t)[(t  >  t  ^'nl)  —>  timerequiredby(mustfinishby(t  ,[p)))  <  (t-tevenl)] 


For 


timerequiredby(mustfinishby(t,{p ] )) 

=  timerequiredbyt,  0), 

timerequtredby({<normal,q>  1  q€  mustcompleteby(t,[p))}), 
mustcompleteby(t,{p\)  =  {q  I  [<?e  \p }  a  Deadline(q)<t] ) 


DL 

ifr>rn, 


i f  mustcompleteby(t.{ p !  )=d 
otherwise 


Therefore, 

timerequiredby(mustfimshbyU.\p\ )) 

=  timerequiredby(6),  if  t<lDL 

timerequiredbyi  (  <normal.p> ) ),  iff  ~lDL 

=  0.  if  t<JDL 

^required' 

If feasible({p))  =  true,  then,  by  definition,  for  any  t  >  t^(nl  .  .  . 
nmerequiredby(mustfinishby{t.[p  J ))  <  (t->evenl) 


For  the  cases  where  t  <tDL.  this  relation  is  trivially  satisfied  since  the  left-hand  side  of  the  relation  is 
equal  to  zero  and  the  nght-hand  side  is  greater  than  or  equal  to  zero  by  definition 
(t  >  t  ,  (t  -  t  >  0).  For  the  cases  where  f  >  fn,  ... 

event  event  l/l* 


? required  ?  ^ event 


1 required 


~  *  DL  t required 


(since  t>tDl) 


Applying  this  general  result  to  each  of  the  three  phases  under  consideration  yields: 

•  feastble(\p\ })  =  true,  iff  tevtnl  <  2ta-fta+l)  =  ta-\ 

•  feasiblef  [p2\)  =  true,  iff  tevrnl  <  2ta-ta-ta 

•  feastble([p3))  =  true,  iff  <  (2ta-l)-(ta-l)  =  rg 


Using  this  information  in  the  previously  derived  expression  for  PtraiMc( [p 3 ) )  yields 
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=  (p?i. 

i{feasible({p3\) 

0, 

otherwise 

=  Ip?). 

>f0 

0, 

if  r  <  r 

a  e\  en: 

=  P feasM&P*  Mpl  1  ^P2 

))•  ifO  <reve„^'fl 

P/ea»Me(PfeasM'l<y'JlPl  »^2  ) 

if'/U 

=  rfe^Pf'a,MMP'^^P2^ 

ifO<r  <r 

e\ent  a 

P feasible^ feasible^P^  )  )w  {p2  }  i , 

(since  feasible({p\ } )=falsefor 
(since  feasible({p2 )  )=false  for  f^,,) 

Consider  the  other  case  in  the  denvation  of  PJ<rWl u/,</lpl-p2.p3}).  where  0  < t^tnt  <ta  ... 


a  rvent 

P  scheduled 

^ feasible 

=  jP/fai,w,Up2)) 
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p  schedule/^1  P2P3^ 

=  P feasible^ feasible'  (P  1  P>3  )  Mp2  (  ) 


'■P feasible^  P3  Mp2})- 

P feasible^ feasible^ Pl  1  -MP2  I  )• 


*W=<> 


(since  />,<-,<ulW,(lpl  p3ji=(pl^3)) 

(Since  P feasible1  IP*  -P3  1  >  =  P :easible{  IP1  1  )) 


=  P feasible^  {pl-p2-P3D- 

lf',v,„l=0 

PfeasAlMPl^P2^' 

(since  feasible!  (pl  );=rrae  ‘ff  t^,fnlita~ 1) 

P  feasible^  P2^’ 

l{V*  < S 'a 

=  P feasible^1  P2P3^' 

if/  =0 

rv  rn/ 

PfeasMe^P1^' 

tfO<r  </  -1 

event  3 

P feasible^  f  P2^' 

ifr  -1  <r  </ 

a  event  a 

~  P feasible^  (P  ^  >P2>P3  1  )> 

i ft  =0 

event 

P feasible^ 1  )  >- 

(since  lpl.p2  ) ) =P feasible^  tP1  1  )> 

P feasible1'  ( P2^' 

if/ -1  </  „  <r 

a  rven/  a 

=  (pl  1, 

if  /  =0  las  shown  previously) 

event 

\P  1). 

(since feasible(\pl  })=true  iff’^em-,a~  1) 

(p2i. 

(since  feasible) \p2 ) )=rrue  iff  t(venJ  <  ra) 

Putting  it  all  together  .  . 

P scheduled  P2*3  D= 

(pl). 

>fOS/,v„,<ra-l 

ip2|. 

if 'a'1  <'**..« 

0, 

if/  <; 

<3  rvrn/ 

Remember  that,  by  definition: 

SelectPhasei[p\.p2.p3})  = 

pickone(mustfinishb\(DLrril(pi 

nplisOJ* schedule J  (P  *  -P2.P3  )  ))>, 

where 

pmphst  =tobescheduled(P schfJuUl/,\p\.p2p>3 ))) 

As  a  consequence  of  these  last  two  points: 

SelectPhasel  [pl,p2.p3 1)= 

<normal,p  1>, 

<normal,p2>. 

'fV1  <te,en,^ta 

<normal,nullphase> , 

'{,a<’esen, 

The  outcome  of  this  portion  of  the  analysis  ls  that  any  number  of  'request  phase'  events  can  occur  to 


Scheduling  Dependent  Real-Time  Activities 


C-101 


reiterate  scheduling  parameters  of  the  three  phases  of  concern.  These  events  will  be  accepted  by  the  lbesa 
automaton  and  the  PhaseElect  state  component  will  have  its  value  changed  as  indicated  above  for 
PhaseElect  =  SelectPhase({p\p2p3)).  The  (possibly  empty)  sequence  of  scheduling  parameter 
reiterations  may  be  broken  by  a  ’resume-phase'  event  for  phase  PhaseElect  at  any  ume 

For  reasons  similar  to  those  offered  earlier,  this  ’resume-phase’  event  may  be  followed  by  any  number  of 
other  'request -phase'  events  for  the  two  phases  that  are  not  executing.  Once  again,  these  'request-phase’ 
events  may  change  the  value  of  the  PhaseElect  phase  component.  In  fact,  the  first  ’request-phase’  event 
occurring  after  the  'resume -phase'  may  cause  a  change  in  value  in  PhaseElect.  thus  potentially  triggering  a 
preemption. 

Since  it  is  difficult  to  follow  a  narrative  description  of  all  of  the  potential  histones  that  may  be  accepted 
by  LBESA,  the  following  approach  is  taken  Consider  the  diagram  below,  where  each  labeled  item  is  an 
event.  "E*"'  indicates  one  or  more  occurrances  of  the  expression  ”E ",  and  "E*"  indicates  zero  or  more 
occurances  of  the  expression  ”E”.  (The  labels  "(Case  X)”  are  merely  used  in  the  ensuing  discussion  to  refer 
to  specific  branches  of  the  diagram.) 

Ei 

Eo 

E3 

E4 

[  Efrtleralr  } 


(Case  I) 

^E  reilc  rate  1 
E6 

^E  reiterate^ 

E7 

[E 

reitrratr  ^ 


(Case  II) 
E< 


(Case  III) 


(Case  IV) 
E0 


where 
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E. 

t|  =  °" 

request-phase(step(vl,  2ta).  ta+l) 

Pi 

E2 

o 

II 

request-phase(step(v2.  2ta).  ta) 

P2 

Ej 

t3  =  0 

request-phase(step{v3.  2ta-l).  ta-l) 

P3 

E4 

‘a 

resume-phase(pfirst) 

S 

E5 

l5 

request-phase(step(0,  °°).  0) 

P  first 

E6 

‘6 

preempt-phase(pfir51) 

s 

E7 

‘7 

resume -phase(pS£cond) 

s 

Eg 

l8 

request-phase(step(0,  »>).  0) 

Psecond 

e9 

*9 

preempt-phase(psecond) 

s 

Ere .ieratc:  'request-phase'  reiterating  scheduling  parameters  for 
a  phase  other  than  RunningPhase 

To  interpret  the  above  diagram,  each  history  accepted  by  LBESA  begins  with  the  first  event.  £;,  which  is 
on  the  first  line  of  the  diagram.  To  trace  an  individual  history  accepted  by  LBESA,  begin  with  the  top  line 
and  proceed  down  one  line  at  a  time.  Where  there  are  branches,  choose  one  path  or  the  other  and  continue 
to  move  down  through  the  diagram.  The  history  may  be  terminated  at  any  time30 

To  demonstrate  that  the  diagram  is  correct,  that  is.  that  it  incorporates  all  of  the  legal  histones  that  lbesa 
will  accept,  consider  the  following  rationale. 

As  was  discussed  earlier,  a  'request-phase'  event  may  be  accepted  at  any  time,  as  long  as  it  serves  only  to 
reiterate  the  already  established  scheduling  parameters  for  a  phase.  As  a  result,  the  diagram  indicates  that 
such  events,  labeled  [Ereilerate]\  may  occur  between  any  other  two  events  in  a  history. 

As  was  also  shown  earlier,  an  examination  of  the  preconditions  of  the  vanous  potential  events  indicates 
that  the  only  event  that  may  be  accepted  after  E,,  Eo.  E3,  and  any  other  reiterative  'request-phase’  events  is 
a  resume-phase’  event  to  start  the  execution  of  the  phase  that  is  currently  designated  PhaseElect  (as  long 
as  PhaseElect  is  not  the  nullphase).  Hence,  E4  can  only  be  a  'resume-phase'  event. 

There  are  two  possible  courses  that  may  be  followed  after  E4:  (a)  the  phase  may  be  preempted  (Case  I)  or 
(b)  it  may  complete  execution  (Case  II).  In  the  latter  case,  if  the  phase  runs  to  completion,  then  it  will 
originate  a  'request-phase'  event  to  signal  that  circumstance.  This  event  will  always  be  accepted  because 
its  precondition  is  simply  true.  In  Case  I,  examination  of  the  precondition  for  a  'preempt-phase'  event 
indicates  that  a  preemption  can  only  occur  if  RunningPhase  is  not  the  same  as  PhaseElect  and  is  not  the 
nullphase.  The  postconditions  of  event  E4  guarantee  that  RunningPhase  is  not  the  nullphase.  Hence,  if  a 
’request-phase'  event  following  E4  yielded  a  value  of  PhaseElect  different  from  RunningPhase ,  then, 
according  to  the  previous  analysis  of  SelectP hase( \p\.p2 1).  the  only  possibilities  are: 

1.  E4  resumed  pi,  and  PhaseElect  subsequently  becomes  either  p2  or  nullphase.  or 

2.  E4  resumed  p2,  and  PhaseElect  subsequently  becomes  the  nullphase 

Currently,  the  assumption  is  made  that  the  required  computation  time  for  a  phase  >  known  exactly. 
Whenever  the  phase  designated  by  PhaseElect  is  resumed  immediately  after  a  request -phase'  event,  it  will 


,0At  any  time  after  ihe  third  event,  that  is. 
and  E r  tn  that  order. 


By  definition,  ihe  oniy  histones  being  considered  are  those  that  begin  with  events  E r  E 
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be  able  to  meet  its  deadline  if  it  runs  uninterrupted  because  a  test  of  feasibility  was  earned  out  that  verified 
exactly  that  fact.  However,  if  time  is  allowed  to  elapse  between  the  'request-phase'  and  the  resume-phase' 
events,  it  is  possible  that  it  is  no  longer  feasible  to  execute  PhaseElea  by  the  time  it  is  actually  unDated^ *. 
Subsequent  request-phase'  events  serve  to  indicate  that  fact  by  selecting  a  PhaseElea  other  than 
RunningPhase.  thereby  setting  the  stage  for  a  preemption. 

Consider  the  next  non- ’request-phase'  event  to  be  accepted  by  lbesa  under  Case  D  in  the  diagram.  If  the 
first  phase  to  execute,  pfint,  completes  execution,  it  signals  this  fact  by  originating  event  E5.  Then  the 
subsequent  evaluation  of  either  PhaseElect=SelectPhase{{p2,p3})  (in  the  case  where  pf  was  pi)  or 
PhaseElecr=SelectPhase({p\p3\)  (in  the  case  where  pf  was  p2)  yields 

PhaseElea  =  <normal,  nullphaso.  Therefore,  no  subsequent  'resume-phase'  event  can  be  accepted  by  the 
automaton  since  the  necessary  precondition  cannot  be  satisfied.  Also,  since  RunningPhase  =  nullphase 
following  E5,  no  new  'preempt-phase'  event  can  be  accepted  either.  So.  except  for  reiterative  'request- 
phase'  events,  no  further  events  can  be  accepted  in  these  particular  histories 

In  Case  I.  where  the  first  phase  to  execute  was  preempted,  this  fact  was  indicated  by  event  Efe.  As  one  of 
its  postcondiuons,  E6  set  RunningPhase  =  nullphase.  The  next  event  in  any  history  accepted  by  LBESA, 
other  than  reiterative  ’request-phase'  events,  cannot  be  another  ’preempt-phase’  event  because  that  would 
require  RunningPhase*  nullphase  Therefore,  if  any  event  other  than  a  reiterative  ’request-phase'  event  is 
to  be  accepted  by  lbesa,  it  must  be  a  ’resume -phase’.  In  order  to  have  such  an  event  occur,  PhaseElect 
must,  as  a  precondiuon,  be  ncm-nullphase.  This  can  result  from  a  reiterative  ’request-phase’  event 
according  to  an  analysis  similar  to  the  one  done  above. 

Finally,  if  E,,  a  ’resume-phase'  event,  is  accepted  in  a  history,  then  the  situanon  and  analysis  is  almost 
identical  to  the  one  that  was  examined  after  event  E4,  the  previous  'resume -phase’.  Once  again,  the 
resumed  phase.  psecor)d  in  this  case,  can  either  be  preempted  (Case  III)  or  run  to  compleuon  (Case  IV).  and 
the  circumstances  for  each  of  these  outcomes  is  exactly  analogous  to  those  given  earlier  for  E4.  However, 
the  earlier  examination  of  SelectPhase({p\ p>2jt3  ()  shows  ’hat  there  is  no  possible  successor  phase  to 
execute  following  either  Eg  or  E?.  In  both  cases,  this  is  due  to  the  fact  that  p^^  must  be  p2  and 
PhaseElea  =  SelectPhase({plp2p>3})  and  PhaseFbrt  SelectPhasei  [p]  p3})  both  yield 
PhaseElect  =  <normal,nullphase>,  which  will  not  permit  a  subsequent  ’resume -phase’  event  to  be  accepted 
by  lbesa. 

While  the  above  arguments  demonstrate  that  the  earlier  diagram  incorporates  ail  of  the  legal  histories  that 
may  be  accepted  by  lbesa,  they  do  not  reveal  all  of  the  factors  involved  in  making  the  histones  acceptable. 
In  particular,  there  are  constraints  on  the  times  at  which  certain  events  occur,  above  and  beyond  those  that 
apply  to  any  legal  history,  that  must  be  satisfied  to  obtain  certain  histones.  For  instance,  depending  on  the 


! 'intuitively,  this  cm  be  though!  of  u  reflecting  «  latency  issue.  In  effect,  the  scheduler  determines  whet  can  be  feasibly  completed 
m  the  available  time  from  the  instant  at  which  a  scheduling  decision  is  made.  However,  if  the  laiency  encountered  in  actually 
dispatching  the  next  phase  is  luge  enough,  then,  by  the  time  it  has  dispatched  the  phase,  the  set  of  phases  that  is  feasible  has  changed. 
Nonce  that  it  is  possible  lo  specify  this  laiency  and  apply  certain  restrictions  to  histones  in  order  to  model  and  accommodate  the 
latency.  Also,  it  is  possible  to  alter  the  algorithm  embedded  in  the  automaton  to  handle  this  latency  when  it  is  determining  PhaseElecl. 
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liming  of  events,  there  is  the  possibility  of  executing  zero,  one,  or  two  phases  during  the  course  of  a  history. 
The  following  list  specifies  the  time  constraints  that  must  be  satisfied  by  various  events  to  obtain  given 
histones: 

1.  if  the  history  includes  event  E4.  then  pfirs!  may  be  either  pi  or  p2;  if  it  is  to  be  pi,  then  r  n( 
for  the  'request-phase’  immediately  preceding  E4  must  saosfy: 

0  S  Ucnr  S  'a-1 

if  pfirst  is  to  be  p2,  then  texenl  for  the  'request-phase'  immediately  preceding  E4  must  satisfy: 

V1  <  W*  5  !a 

2.  if  the  history  includes  event  E6  (Case  I),  then  either: 

a.  pf  =  pi  —  in  this  case,  t4,  the  time  at  event  which  E4  occurred,  must  have  satisfied: 

<  f4 

b.  pf  =  p2  —  in  this  case,  t4,  the  time  at  event  which  E4  occurred,  must  have  sausfied: 

'a  <  '4 

3.  if  the  history  includes  event  E<  (Case  II).  then  either32: 

a.  pfirsl  =  pi  —  in  this  case,  t5,  the  time  at  event  which  E5  occurs,  must  satisfy': 

!s  =  'a  +('a+1> 

since  required  computation  time  is  known  accurately. 

b.  pfir5t  =  p2  —  in  this  case,  t5,  the  time  at  event  which  E;  occurs,  must  satisfy: 

t,  =  t.  +  t 

5  4a 

since  required  computation  time  is  known  accurately. 

4.  if  the  history  includes  event  E^ ,  then  pfirst  must  be  pi  and  p,^^  must  be  p2.  In  addition, 
t^enl  for  the  ’request-phase’  immediately  preceding  E7  must  satisfy: 

'a*1  <  S  'a 

5.  if  the  history  includes  event  Eg  (Case  IV),  then  t^,  the  time  at  event  which  Eg  occurs,  must 
satisfy33: 

'8  =  h  +  ’a 

since  required  computation  time  is  known  accurately. 

6.  if  the  history  includes  event  Eg  (Case  III),  then,  since  pf  =  p2,  t7,  the  tune  at  event  which  E- 
occurred,  must  have  satisfied: 

<  h 


Once  all  of  the  histories  that  are  accepted  by  lbesa  have  been  enumerated,  their  respecuve  values  can 
also  be  enumerated.  To  that  end,  the  table  shown  in  Figure  4-7  puts  all  of  the  preceding  pieces  of  the 
argument  together.  It  lists  ad  of  the  histories  accepted  by  lbesa  that  start  with  events  E , .  E,,  and  E3.  along 
with  their  corresponding  values. 

’“This  is  actu»lly  a  requirement  of  any  legal  history.  It  is  explicitly  listed  here  since  it  does  point  out  an  important  time  constraint 
for  the  history  that  otherwise  might  be  forgotten. 

33Once  again,  thi5  is  actually  a  requirement  of  any  iegai  history  and  is  oniy  included  here  for  the  sake  of  completeness. 

l4The  value  at  this  point  will  be:  la)  vl,  if  pr^t  =  p  1  and  t4  £  t  -1.  (b)  v2.  if  =  p2  and  t4  £  t#,  or  »c;  0,  .n  ail  other  cases. 

35Same  conditions  as  in  the  previous  case  determine  the  actual  value. 

3frThe  value  at  this  point  will  be:  'a)  v2,  if  U  £  t#.  or  tbi  0.  otherwise. 

37Same  conditions  as  in  the  previous  case  determine  ihe  actual  value. 
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History 

Value 

E>E:E3 

0 

E.E:E3[Ereil£raJ* 

0 

ErE:  E3'[Ereil£rij‘-E4 

0 

EIE2E3[Erel|erilc]*E4fEre.ttri,ie 

• 

0 

E[  E;  E3  [Erellcrale]  Ea'^reurratc 

*  E5 

0,  vl ,  or  vl34 

ErE2'E3'[Ere^aj’'E4'[Eml£rat£ 

E5  ^rcit£rate) 

0,  vl ,  or  v2j5 

EIE:E3[Ereil£raJ  E4'[Ere|1£ratc 

*  TE  1* 

1  rr  iterate-1 

■ 

0 

E,  E;  E3  [Ereit£ralc]  E4  [Ereit£rat£ 

^reiterate^  ^6 

0 

E.  E2  % ■[£„,«.«]*  E4  [E^ra* 

P^reiteratrJ  ^6  t^rcilcralc ^ 

o 

E 1  E2  E3  ^Ereueraie  1  *  E4  ^ErcueratJ 

■•IE*,  ttr.Kr-H6-[EieiIer.Ie]*-E: 

0 

E$  H2  £3  [Hrei(cralc]--E4  [Hre||erale 

*  Preiteraifl*  E6  [Ereiteratt]*  E-  [Breiu.rau.]* 

0 

El-E2E3-[Ewller,Ie]'.E4-[EleileiMe 

fErtitcraie^  E6  ^rciteratt}  E-T^E  re  Herald  E8 

I  0  or  v236 

E1E2E3 

[EfeileralJ  Eo  ^Err;ieratr^  E"?  ^reiterate-  E8 

!  0  or  v23 ' 

.[e  r 

1  rcilcraicJ 

E,-E:  E3  [Ereilerale]  E4  [Ereti£raie 

^reitcraitJ  E6  [Ereu«ratJ  -E7  ^reneraicl 

0 

^EreucratcJ 

E,  E2  E3  [Erei[cratc]  E4  [Ercitcratr 

*  [EI«.ttr.«l*E6-[Ereilerale]*-E7  [Ereiterater 

0 

!ErcilcratJ  E9 

i 

E.-E,  E,  [E  I’-E.  iE 

1  2  3  L  rcii£raicJ  4  1  reiterate 

tEfeUeraleJ  E6  iErriicralJ  -E7  ^reilerait^ 

0 

t^reitcratJ  '^9  ^reiterate  1 

. 

i 

Figure  4-7:  Histones  Accepted  by  lbesa  Beginning  With  e,  E,  e3 

The  maximum  total  value  of  any  history  accepted  by  lbesa  is  »mu(0,vl,v2i.  Since  vl  and  v2  are  both 
greater  than  zero,  this  is  equal  to  max(vl,v2).  Also,  from  the  initial  value  density  relations,  it  is  known  that: 
vl/ra+l>v2/ra 


Therefore, 
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vl/a>v2(ra+l) 
v2  (q+1)  =  v2  ta  +  v2  >  v2  ta 
vlta>v2(ta+l)>v2ta 
vl  >  v2 

Consequently,  the  maximum  total  value  for  any  of  the  histones  in  the  table  is  mrer(vl,v2)  =  vl. 

As  shown  in  the  first  section  of  this  proof,  DASAAD  accepts  a  history  with  value  (vl-*-v3)  starting  with 
these  three  events,  while  the  maximum  value  for  a  history  accepted  by  LBESA  is  vl.  Therefore,  there  exists 
a  case  in  which  dasa/ND  accepts  a  history  with  greater  value  than  LBESA.  and  there  is  no  transformation  of 
that  history  or  alternate  history  dealing  with  the  same  phases  and  scheduling  parameters  that  allows  LBESA 
to  obtain  an  equal  or  greater  value  than  dasa/ND. 

f  EndOfProof 


Since  the  dasaad  Scheduling  Automaton  is  equivalent  to  the  dasa  Scheduling  Automaton  when  there 
are  no  dependency  considerations,  the  result  extends  to  the  dasa  Scheduling  Automaton  as  well. 

4.3.3.  Algorithm  Tractability 

This  section  examines  the  computational  complexity  of  the  dasa  scheduling  algorithm.  Specifically,  the 
amount  of  time  and  space  required  for  the  Dasa  algorithm  to  select  a  phase  to  execute  is  derived.  Of 
course,  the  lower  the  complexity  of  a  computation,  the  more  feasible  it  is  perform.  In  general,  problems 
that  have  exponential  complexity  are  deemed  intractable,  while  those  that  have  a  low  polynomial 
complexity  are  considered  tractable. 

43.3.1.  Procedural  Version  of  dasa 

It  is  possible  to  use  the  definition  of  the  ‘SelectPhaseO’  function  presented  in  Section  3. 2. 1.3  to 
investigate  the  computational  complexity  of  the  algorithm.  However,  it  seems  to  be  somewhat  easier  to 
analyze  a  procedural  definition  of  the  function. 

Figure  4-8  shows  a  procedural  definition  of  the  Dasa  scheduling  algorithm. 

Where  possible,  the  variable  names  in  the  procedural  definition  are  taken  from  the  corresponding  state 
components  in  the  das,\  Scheduling  Automaton. 

The  language  employed  for  the  definition  is  similar  to  Algol  or  Pascal.  The  control  statements 
(if-then-else,  for,  and  while)  may  delimit  blocks  of  code  and  are  explicitly  terminated  (with  endif,  endfor, 
and  endwhile ,  respectively)  to  avoid  any  ambiguity.  The  for  statement  is  used  to  step  through  an  ordered 
list,  one  entry  at  a  time.  The  variables  in  the  for  statement  take  on  the  values  dictated  by  the  current 
element  in  the  list.  The  exirfor  statement  causes  control  to  pass  to  the  statement  following  the  innermost  for 
loop  enclosing  the  exitfor  statement. 


(note  that  ta> 0) 
(since  v2>0) 
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SelectPhaseProc(PhaseList)  ( 
;  variable  declarations 
schedule 
real 
phase 

ordered  list  of  phase 
mode 


Sched.  TentSched 

TotalTime.  TotalValue.  CurrentDeadline.  DL 
P,  NextP,  PnorP,  CurrentPhase 
PhaseList.  SortedList 
SchedMode,  Mode 


.  create  an  initially  empty  schedule 
Sched  =  emptyschedule 

,  construct  the  dependency  list  and  determine  PVD  for  each  phase 
for  P  in  PhaseList 

if  (ExecMode(P)  =  normal)  then 
TotalTime  =  ExecGock(P) 

TotalValue  =  Val(P) 

DependencyList(P)  =  emptylist 
NextP  =  Ownert  ResourceRequestedfP)) 

SchedMode  =  normal 
.  follow  chain  of  dependencies 
while  ((NextP  *  nullphase)  a  (SchedMode  *  abort)) 
if  (ExecClockfNextP)  <  AbortClock(NextP))  then 

;  update  dependency  list  and  adjust  accumulated  value  and  time 
Dependency List(P)  =  DcpendencvList  ccomplete.  NextP> 
TotalTime  =  TotalTime  +  ExecClock(NextP) 

TotalValue  =  TotalValue  +  Val(NextP) 

else 

DependencyList(P)  =  DependencyList  <abort,  NextP> 
TotalTime  =  TotalTime  +  AbortClock(NextP) 

,  note  TotaA'alue  remains  unchanged 
SchedMode  =  abort 
endif 

.  advance  lo  next  phase  in  dependency  list 
Next P  =  OwneriResourccRequestedfNextP)) 
endwhile 

PotentialValueDensity(P)  =  TotalV'alue/TotalTime 

else 

;  if  aborting  phase,  there  is  no  value  to  be  gamed  directly 
PotentialValueDensity(P)  =  0 
endif 
endfor 

.  form  a  sorted  list  of  phases  according  to  potential  value  density 
.  (highest  PVD  first  m  list,  lowest  PVD  last I 
SortedList  =  ScrtByPVDf  PhaseList) 
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Figure  4-8:  Procedural  Definition  of  Dasa  Scheduling  Algorithm 


The  following  simple  functions  are  used  in  the  algorithm  definition: 

Insert(element,  orderedlist,  key) 

inserts  element  in  list  orderedlist  at  the  position  indicated  by  key;  if  there  are  already 
entries  in  the  list  with  key  value  key,  insert  element  before  them. 
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;  look  at  each  phase  in  turn 
for  P  in  SortedList 

,  if  it  has  any  potential  value,  attempt  to  add  it  to  schedule  46 

if  (PotenualValueDensity(P)  >  0)  then 

;  only  add  completion  if  it  hasn't  already  been  heduled 
if  (ccomplete,  P>  e  Sched)  then 

,  get  a  copy  of  the  schedule  for  tentative  changes 

TentSched  =  Sched  5 1 

,  tentatively  add  '  P’  and  its  dependency  list  to  the  schedule 
Insert(<complete,  P>.  TentSched,  Deadline(P)) 

CurrentDeadline  =  Deadline(P) 

CurrentPhase  =  P 

.  tentatively  add  phases  in  dependency  list  to  schedule  56 

for  <Mode,  PriorP>  in  Dependency ListfP) 
if  (<Mode,  PriorP>  G  TentSched)  then 

,  see  if  the  phase  is  scheduled  soon  enough 
DL  =  Lookup(<Mode,  PnorP>,  TentSched) 

if  (DL  <  CurrentDeadline)  then  61 

,  it  is:  nothing  else  to  do  so  exit  the  loop 
exitfor 

else 

Remove(<Mode,  PnorP>,  TentSched,  DL) 
endif  66 

endif 

if  (Mode  =  normal)  then 

CurTeniDeadiine  =  MinfCurrentDeadiine,  Deadlmei'PnorP)) 

else 

,  CurrentDeadline'  remains  unchanged  71 

endif 

,  tentatively  add  phase  to  schedule 
Insert(<Mode,  PncrP>,  TentSched,  CurrentDeadline) 
endfor 

,  clean  up  tentative  schedule,  as  required  "6 

examine  current  simplifications;  make  less  brute  force 
.  test  the  feasibility  of  the  tentative  schedule 
if ' FeasiblefTentSched))  then 

,  incorporate  all  of  the  tentative  changes  into  the  schedule 

Sched  =  TentSched  81 

else 

,  'Sched'  remains  unchanged 
endif 
endif 

endif  86 

endfor 

.  select  first  phase  to  execute 
return!  First!  Sched)) 


Figure  4-8:  Procedural  Definition  of  DASa  Scheduling  Algorithm,  continued 
Removelelement,  ordcredlist.  key) 

removes  element  from  list  orderedhst  at  the  posiuon  indicated  by  key:  if  element  is  not 
present  at  that  position  in  the  list,  the  function  takes  no  acuon. 
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Lookuptelement.  orderedlistt 

returns  the  key  value  associated  with  the  first  occurance  of  element  in  list  ordered',  r; 
First!  orderedhst)  returns  the  first  element  in  list  orderedhst 
SortBy  PVDiphase'ist) 

returns  a  list  of  phases  ordered  by  decreasing  PVD;  if  two  or  more  phases  have  the 

same  PVD,  then  the  phase  or  phases  with  the  greatest  required  execution  ume 

( ExecCIock )  appear  before  any  others  with  die  same  PM) 

Feasible!  orderedhst) 

returns  a  boolean  value  It rue  or  falsa  indicating  w  hether  the  schedule  represented  by 
orderedhst.  an  ordered  list  of  mode-phase  pairs,  constitutes  a  feasible  schedule,  as 
defined  previously  (by  the  function  feasible )  in  Section  3.2.1 .3  i. 

.Mm(x,  y)  returns  the  minimum  of  a  and  i 

Briefly,  the  procedure  consists  of  four  stages.  First,  each  phase  is  examined  to  determine  its  potenurl 

value  density  and  to  construct  its  dependency  list  Second,  the  phases  are  sorted  and  placed  into  an  ordered 

list  mnked  by  their  PVD.  Next,  a  schedule  is  constructed  by  attempting  to  add  each  phase,  along  with  all  of 
the  other  phases  in  its  dependency  list,  to  the  evolving  schedule.  !f  this  addition  produces  a  feasible 
schedule,  then  the  phase  is  included  m  the  schedule;  otherwise,  it  is  not.  (Some  simplifications  of  the 
evolving  schedule  occur  at  this  point  as  wcll.y  Finally,  after  ail  of  the  phases  have  been  considered  for 
inclusion  in  the  tentative  schedule,  the  schedule's  first  e'ement  is  selected  for  immediate  execution 

The  schedule  created  by  the  SeltciPhaseProtf i  procedure  is  an  ordered  list  of  mode-phase  pairs,  each 
placed  according  to  the  deadline  it  must  meet.  So,  for  instance,  a  phase  the  must  meet  a  deadline  at  ume 
t  -  1  will  precede  a  phase  that  must  meet  a  deadline  at  time  t  -  2  in  the  schedule  If  more  than  one  phase 
must  meet  a  single  deadline,  then  the  mode-pha.e  pair  that  w  as  added  to  the  schedule  last  will  he  executed 
first 

Notice  that  the  deadline  a  mode-pha.se  pair  must  meet  is  not  necessarily  the  deadline  associated  with  that 
phase.  In  fact,  the  phase  may  need  to  meet  an  earlier  deadline  in  order  to  enable  another  phase  to  mec'  its 
time  constraint.  Whenever  a  phase  Ls  considered  for  insertion  in  the  tentative  'chcdu'e  Mine  47  of  Figure 
4-8,i,  it  is  scheduled  to  meet  its  own  tunc  constraint.  However,  all  ot  me  mode-phase  pairs  in  its 
dependency  list  must  execute  before  it  can  execute,  and,  therefore,  must  precede  it  in  the  schedule. 

The  variable  CurrentDeadltne  is  used  in  Seiet tPhaseProt  <  ,i  to  keep  track  of  this  type  of  scheduling 
consideration  Initially,  it  is  set  to  be  'he  deadline  of  the  phase  to  be  tentatively  added  the  schedule 
Thereafter,  any  mode-phase  pair  that  has  a  later  time  constraint  than  CurrentDeadltne  is  required  to  meet 
CurrentDeadltne.  If.  however,  a  mode -phase  pair  has  a  tighter  deadline  than  Currrr.il n  adhne .  then  it  is 
scheduled  to  meet  the  tighter  deadline,  and  CurrentDeadltne  us  advanced  to  that  time  since  all  of  the 
mode-phase  pairs  left  in  tlic  dependency  list  must  complete  by  then. 


The  major  data  stmeturcs  used  by  Seiet  tPhasrProd  i  arc: 

1.  a  Phase  Control  Block  tPCBi  for  each  phase  to  be  scheduled  -  it  contains  a  phare  id  the 
necessary  scheduling  parameters  RwModc.  Hxu  Clot  k.  AhottCT-t  k.  Dt.idttnr  V  a'.ue.  the 
names  of  any  currently  requested  ot  held  shared  resources,  a  reference  to  a  dependency  list, 
and  a  reference  to  another  pha>c  that  i,  used  to  chain  PCBs  togethci  to  tom;  ’he  Pha  <  List. 
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2.  PhaseList  is  simply  a  reference  to  the  first  phase  in  the  list;  subsequent  phases  in  the  list  are 
found  by  following  the  phase  reference  field  in  the  PCBs; 

3.  SonedList  is  simply  an  ordered  list  of  references  to  the  PCBs; 

4.  dependency  lists  are  linked  lists  of  mode-phase  pairs,  each  of  which  refers  to  a  specific  PCB; 

5  schedules  are  ordered  lists  of  mode-phase  pairs;  although  many  data  structures  may  be 
sufficient,  assume  a  balanced  binary  tree  is  used  here-58  (for  example,  a  2-3  tree);  then  insert, 
remove,  lookup  and  find  minimum  operations  can  all  be  done  in  Oilog  N)  time  and  O(N) 
space  for  a  set  of  \  phases. 


4_3J.2.  Proof:  Procedural  Version  of dasa  Is  Polynomial  in  Space  and  Time 

Given  the  definition  of  SelectPhaseProcQ,  it  is  possible  to  demonstrate  that  it  requires  an  amount  of 
space  and  time  that  is  proportional  to  a  polynomial  power  of  the  sue  of  the  problem:  the  number  of  phases 
requesting  to  be  scheduled. 

Theorem  4:  Given  N  phases  to  be  scheduled  using  the  Dasa  scheduling  algorithm,  show  that 
SelectPhaseProc{)  will  determine  the  first  phase  to  execute  in  0(N‘  log  N)  time. 


Proof.  To  determine  the  time  required  by  SeiectPhaseProcQ.  examine  the  amount  of  time  required  for 
each  of  its  component  steps: 

1.  create  an  initially  empty  schedule  (lines  9-10):  0(1),  this  requires  constant  time  for  virtually 
any  list  structure. 

2.  construct  the  dependency  list  and  determine  PVD  for  each  phase  (lines  1 1-40):  0(N:),  since: 

a.  the  for  loop  begun  at  line  12  is  executed  N  times,  once  for  each  phase; 

b.  if  the  ExecMode  of  the  phase  is  not  normal,  then  the  loop  body  takes  0(1)  time  to 
execute  (it  is  a  single  assignment  statement,  lines  37-38);  however,  if  the  ExecMode  is 
normal ,  then  loop  body  takes  O(N)  to  execute  since: 

i.  lines  14-18  require  0(1)  time; 

ii.  because  there  are  no  deadlocks,  there  can  be  no  circular  dependency  lists; 
therefore,  the  while  loop  at  line  20  will  be  executed  less  than  N  times,  and  each 
time  lines  21-33  require  0(1)  time;  hence  the  entire  while  loop  requires  O(N) 
time  to  execute  in  the  worst  case; 

iii.  line  35  requires  0(1)  time; 

3.  form  a  sorted  list  of  phases  according  to  potential  value  density  i  lines  41-43):  O(NlogN)  if  any 
of  a  number  of  standard  sorting  algonthms  are  used  (for  example,  heap  son); 

4.  tentatively  add  each  phase  in  turn  to  the  schedule  (lines  44-87):  0(N“  log  N).  sit.ee: 

a.  the  body  of  the  for  loop  at  line  45  will  be  executed  \  times,  once  for  each  phase, 

b  the  loop  body  takes  0(1)  time  to  execute  if  the  phase's  PVD  is  less  than  or  equal  to 
rero  or  if  the  completion  of  the  phase  has  already  been  scheduled;  otherwise,  it 
requires  0(>  log  N)  because; 

i.  copying  the  schedule  (lines  50-51)  can  be  done  in  OtN)  time  in  a 
straightforward  manner, 


5,Oiven  a  specific  type  of  application.  experience  may  indicate  that  there  are  better  data  structures  for  schedules  for  example,  if 
there  are  typically  only  a  few  phases  ready  to  execute,  then  a  simple  imear.  linked  list  may  he  sufficient  fhe  tree  structure  was 
selected  for  generality  .and  because  it  wi'l  accommodate  large  numbers  of  phases  and  dependencies  gracefully. 
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ii.  inserting  the  completion  of  the  phase  into  the  schedule  dines  52-53)  can  be 
done  in  Odog  s)  time  since  there  are  at  most  2 N  mode-phase  pairs  in  the 
schedule  (corresponding  to  an  abort  and  a  normal  completion  for  each  of  the  N 
phases'); 

111  setting  up  some  vanables  for  bookkeeping  (lines  54-55)  requires  0(  1)  time; 

iv.  the  for  loop  dines  56-75)  requires  0(N  log  N)  time  since  the  loop  will  be 
executed  fewer  than  N  times  and  each  execution  will  require  0(log  \)  time  to 
perform  insert,  remove,  and  lookup  operations  on  the  tentauve  schedule; 

v.  testing  the  feasiblity  of  the  tentative  schedule  (lines  78-79)  requires  0(s  log  s) 
time  since  it  can  be  done  by  looking  up  each  of  the  scheduled  mode-phase 
pairs  in  order,  summing  execution  requirements,  and  comparing  those 
requirements  to  the  actual  available  time;  this  requires  N  lookups,  each 
requiring  0(log  N)  time; 

vi.  incorporating  all  of  the  tentative  changes  into  the  schedule  dines  80-81) 
require  O(N)  time;  this  can  be  done  by  copying  the  N  nodes  that  comprise  the 
tentative  schedule  over  the  existing  schedule  entnes; 

5.  select  first  phase  to  execute  dines  88-89);  O(log  S)  time 
Therefore,  the  overall  time  to  execute  SelectPhaseProci)  is  0(N2  log  N). 

!  EndOfProof 


The  preceding  proof  uses  straightforward  data  structures  and  algorithms.  An  actual  implementation  may 
be  able  to  improve  on  these.  For  instance,  a  number  of  the  calculations  performed  to  compute  the  PVD  for 
each  phase  could  be  avoided  if  it  was  noted  that  the  phase  and  its  dependency  list  had  not  changed  since  the 
last  execution  of  SelectPhaseProci).  Such  an  optimization  trades  storage  for  speed.  Other  similar 
opnmizations  may  bring  additional  savings. 

Theorem  5:  Given  N  phases  to  be  scheduled  using  the  Dasa  scheduling  algorithm,  show  that 
SelectPhaseProci)  will  determine  the  first  phase  to  execute  using  0(N2)  space. 

Proof.  The  space  required  for  SelectPhaseProci)  consists  of: 

1.  a  PCB  for  each  phase  to  be  scheduled  —  this  requires  OfS)  space; 

2.  two  schedules.  Sched  and  TentSched ,  each  of  which  is  a  balanced  binary  tree  with  at  most  2n 
nodes  —  this  requires  O(N)  space, 

3  space  for  SortB\PVD{)  to  sort  the  phases  (actually,  it  will  sort  a  set  of  keys  that  refer  to 
individual  PCBs)  —  this  requires  O(S')  space, 

4  space  for  each  phase's  DependencyList  —  this  requires  O(S)  space  for  each  phase  in  the 
worst  case,  thereby  requiring  0(N2)  space  overall  in  the  worst  case39; 

5  various  scratch  vanables  —  this  requires  0(1)  space. 

Putting  these  requirements  together,  it  is  seen  that,  in  the  worst  case,  SelectPhaseProci)  may  require 
0(N2)  space. 


,'*rhis  would  truly  be  unusual.  In  order  to  have  very  long  dependency  lists  for  each  phase,  the  system  would  have  to  be  nearly 
deadlocked  and  e»cry  phase  would  have  to  be  close  enough  to  completing  its  normal  execution  that  it  would  lake  longer  to  abort  than 
to  let  it  complete  normally. 
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Notice  that  there  is  no  mention  of  the  storage  required  to  track  the  ownership  and  state  of  each  of  the 
shared  resources  in  the  system.  This  is  ignored  because  it  is  iniormauon  that  is  always  maintained  by  the 
system  for  any  resource  management  or  scheduling  algonthm  No  additional  cost  is  imposed  by  the  dasa 
algorithm. 

EndOfProof 


4.4.  Notes  on  Algorithm 

The  proofs  presented  in  this  chapter  have  allowed  the  behavior  of  the  dasa  scheduling  algonthm  to  be 
witnessed  under  specific  circumstances,  providing  more  understanding  of  the  algonthm.  This,  coupled 
with  the  algonthm 's  formal  definition,  may  suggest  situations  where  dasa  may  exhibit  unusual  or 
unexpected  behavior. 

Each  of  the  following  sections  discusses  one  such  situation  and  the  attendant  algonthm  behavior  Where 
appropnate,  methods  for  handling  the  situation  are  also  mentioned. 

4.4.1.  Unbounded  Value  Density  Growth 

While  value  density  and  potential  value  density  are  appealing  because  they  allow  the  application  to  make 
the  best  use  of  the  processor  time  consumed  by  each  phase,  they  also  display  an  interesting  behavior  when 
the  required  computation  ume  to  complete  a  phase  approaches  zero:  the  value  density,  which  is  value 
divided  by  required  computation  time,  becomes  unboundedly  large. 

This  can  have  some  unexpected  effects,  since  —  given  a  sufficiently  short  required  computauon  time  — 
Dasa  will  favor  executing  a  phase  with  a  very  low  actual  value  over  a  phase  with  an  extremely  high  actual 
value  that  requires  more  time.  In  fact,  this  is  arguably  the  proper  decision  to  make,  given  that  the 
scheduler's  objective  is  to  maximize  total  value  to  the  application,  lot  to  execute  the  phase  with  the 
greatest  value. 

When  assigning  values  to  phases,  an  application  designer  may  wish  to  insure  that,  under  any 
circumstances,  a  given  phase  will  be  selected  for  execution  over  another  phase.  In  order  to  do  this,  the 
designer  must  insure  that  the  value  density  of  the  desired  phase  is  always  the  greater  of  the  two  value 
densities.  However,  if  the  value  density  can  grow  unboundedly  large,  then,  in  general,  there  is  no  way  to 
guarantee  that  the  value  density  of  one  phase  will  always  be  greater  than  that  of  another  phase. 

A  few  facts  miugaic  this  problem,  though.  For  one  thing,  required  computation  time  will  never  reach 
zero  because  if  it  did  the  phase  would  be  done  and  would  not  be  involved  in  scheduling  decisions. 
Therefore,  there  is  a  limit  on  how  small  the  required  computation  time  can  be.  Hence  there  is  also  a  bound 
on  how  large  a  value  density  can  grow  The  application  designer  can  use  this  bound  to  assign  values 
appropriately. 
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If  that  bound  is  deemed  to  be  too  large,  then  a  smaller  bound  can  be  imposed  by  specifying  a  minimum 
amount  of  computation  time  that  may  be  requested  for  compleung  a  phase.  If  a  required  computation  time 
parameter  should  ever  be  smaller  than  this  minimum,  then  the  minimum  value  should  be  used  in  its  place 
when  applying  the  Dasa  scheduling  algorithm 

Evaluating  the  value  density  associated  with  a  phase  only  once,  at  the  time  of  the  phase's  initiation, 
would  also  have  the  effect  of  avoiding  the  practically  unbounded  growth  of  value  densities  The  basic 
information  encoded  into  the  value  density  metric  would  remain  the  same  and  would  be  captured 
effectively.  However,  the  benefit  that  anses  from  evaluating  the  value  density  for  each  schedulig  decision 
would  be  lost  —  that  is.  there  would  no  longer  be  a  nsing  value  density  to  indicate  that  for  a  relatively 
small  investment  of  processor  cycles,  a  large  return  in  appLicauon  value  could  be  realized. 

4.4.2.  Idle  Intervals  During  Overload 

Dasa  is  not  optimal;  it  is  a  heuristic  that  does  well  according  to  important  metrics  for  the  class  of 
real-time  supervisory  control  applications.  However,  there  are  overload  situations  where  it  can  be  less 
effective  than  other  scheduling  algorithms. 

dasa  constructs  a  schedule  by  sucessively  adding  activities  that  have  the  h.ghest  PVDs.  In  this  way,  each 
time  an  activity,  along  with  any  other  activines  on  which  it  depends,  is  added  to  the  tentative  schedule, 
dasa  is  getting  the  greatest  amount  of  value  for  the  proressing  cycles  that  are  then  reserved  for  those 
activiues.  (If  any  other  activity  could  yield  more  value  for  those  processor  cycles,  it  would  —  by 
definition  —  have  a  higher  PVD.  But  all  of  the  activities  with  a  higher  PVD  that  can  be  feasibly  scheduled 
have  already  been  added  to  the  tentative  schedule.) 

LBESa  adds  activities  to  a  schedule  according  to  the  nearness  of  their  deadlines;  and.  in  case  of  an 
overload,  it  sheds  the  activities  with  the  lowest  PVDs  until  a  feasible  activity  is  obtained  As  shown  in 
Section  4.3.2  4,  lbesa  may  shed  some  activities  that  can  be  included  in  a  schedule.  This  can  result  in 
lbesa  utilizing  fewer  processor  cycles  than  dasa  in  a  given  situation. 

The  factors  discussed  in  the  previous  paragraphs  can  collectively  yield  a  situation  where  lbesa  can 
produce  a  schedule  representing  a  higher  value  to  an  application  than  can  Dasa  For  instance,  consider  an 
application  consisting  of  three  activiues,  each  of  which  has  only  a  single  phase  The  phases  are  designated 
Py  p2-  and  py  respectively.  Furthermore,  assume  that  at  ume  /  =  0  the  following  conditions  hold  (using  the 
notauon  for  the  scheduling  automata): 
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Deadlineip  <  Deadlineip ■,)  <  Deadlineip 3) 

PVD(p2)  >  PVD(px )  >  PVD(p2) 

ExecClockip ,)  <  Deadlineip [) 

ExecClock(p2)  >  Deadlineip 2) 

ExecClockip^)  <  Deadlineip 3) 

ExecClockip [)  +  ExecClockip 3)  >  Deadlineip 3) 

Among  other  things,  these  conditions  indicate  that  phase  p2  cannot  be  completed  by  its  deadline,  even  if 
no  other  phases  are  executed.  Also,  either  phase  px  or  phase  p3,  but  not  both,  can  meet  their  deadlines. 

When  dasa  is  presented  with  this  situation,  it  constructs  a  tentative  schedule  by  examining  each  phase  in 
order  of  decreasing  PVD.  Consequently,  it  will: 

1.  add  phase  p-,  to  the  (initially  empty)  tentanve  schedule,  determine  that  the  schedule  is  not 
feasible,  and  shed  phase  p2 

2.  add  phase  p,  to  the  tentative  schedule  and  determine  that  the  schedule  is  feasible 

3.  add  phase  p3  to  the  tentative  schedule,  determine  that  the  schedule  is  not  feasible,  and  shed 
phase  p3 

This  results  in  a  tentative  schedule  that  contains  only  phase  Mathfp,]. 

When  LBESA  is  presented  with  this  situation,  it  constructs  a  tentative  schedule  by  examining  each  phase  in 
order  of  increasing  deadline.  Consequently,  it  will: 

1.  add  phase  p,  to  the  (initially  empty)  tentanve  schedule  and  determine  that  the  schedule  is 
feasible 

2.  add  phase  p2  to  the  tentative  schedule,  determine  that  the  schedule  is  not  feasible,  shed  phase 
p,,  determine  that  the  schedule  is  still  not  feasible,  and  shed  phase  p;  (leaving  an  empty 
tentative  schedule) 

3  add  phase  p3  to  the  tentative  schedule  and  determine  that  the  schedule  is  feasible 
This  results  in  a  tentative  schedule  that  contauns  only  phase  p3. 

Comparing  the  results,  whenever  the  value  associated  with  phase  p3  is  greater  than  that  associated  with 
phase  p,.  then  lbesa  will  accrue  a  higher  value  than  Dasa.  In  addinon.  this  implies: 

Valuelp 3)  >  Valueip^ ) 

— *  ExecClockip 3)  x  PVDlpJ  >  ExecClockip |i  x  PVD(p^) 

ExecClockip -,) 

— *  - —  x  PYDip- j)  >  PVDlp.)  (  >  P\D(py).  from  above  } 

—*  ExecClockip 3)  >  ExecClockip  ^ 

For  the  DASA-produced  schedule,  the  processor  is  idle  for  Deadline' p })  -  ExecClockip ( >  units  of  time, 
while  for  the  LBESA-produced  schedule,  the  processor  is  idle  (or  Deadlineip^)  -  ExecC!oikipx)  units  of 
time  Therefore,  the  schedule  produced  by  dasa  has  more  idle  time  than  the  one  produced  by  lbesa  — 
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even  though  there  is  an  overload  and  two  of  three  phases  that  were  known  to  the  scheduler  were  shed 
Consequently,  by  executing  an  activity  with  a  lower  value  density  for  a  long  enough  time,  while  the  Dasa 
scheduler  is  forced  to  leave  the  processor  idling,  lbesa  can  accme  a  greater  value  than  dasa  for  an 
application 

4.4.3.  Cleverness  and  System  Dynamics 

The  applications  of  interest  for  this  research  are  by  nature  dynamic.  A  scheduler  must  be  able  to  react 
dynamically  in  order  to  produce  effective  schedules  for  these  applications 

Yet  there  is  a  balance  to  be  struck.  The  more  information  that  is  used  to  make  scheduling  decisions,  the 
better-informed  the  decisions  are.  This  typically  results  in  better  scheduling  decisions.  On  the  other  hand, 
each  decision  is  made  based  on  the  best  information  available  at  the  time  of  the  decision.  At  any  point 
thereafter,  circumstances  may  change  —  a  new  request  may  be  made  for  a  shared  resource  or  new  acuvities 
may  arrive  to  be  scheduled  —  demanding  that  new  scheduling  decisions  be  made,  possibly  resulting  in 
undoing  some  previously  accomplished  work. 

Intuitively,  the  more  dynamic  and  unpredictable  an  application  is.  the  less  appropriate  clever  (read 
"time-consuming")  scheduling  schemes  are.  The  actual  dividing  line  for  this  decision  is  not  clear  in 
general.  The  simulations  in  the  following  chapter  demonstrate  dasa's  performance  in  various  situations 
and  take  into  account  the  amount  of  time  required  to  make  scheduling  decisions.  In  fact,  the  simulator 
could  be  used  to  determine  the  effectiveness  of  the  Dasa  scheduling  algorithm  compared  to  another 
algorithm  for  any  application 
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Chapter  5 
Simulation  Results 


The  formal  analysis  presented  in  the  previous  chapter  shows  that  the  dasa  algorithm  possesses  some 
desirable  properties.  These  properties  were  demonstrated  by  comparing  the  behavior  of  dasa  to  other 
known  algorithms.  However,  this  analysis  did  not  evaluate  the  use  of  the  Dasa  algorithm  in  particular 
situations,  nor  did  it  quantify’  the  gains  that  could  be  realized  by  using  dasa  to  schedule  specific  workloads 
Simulations  were  employed  to  examine  these  issues,  and  that  work  is  described  in  this  chapter. 

Secnon  5.1  discusses  the  design  and  implementation  of  the  simulator  used  to  evaluate  dasa  and  other 
scheduling  algonihms.  Section  5.2  presents  results  generated  with  the  simulator  to  evaluate  the 
performance  of  the  Dasa  scheduling  algorithm  Finally,  Section  5.3  hypothetically  charactenzes  two 
real-time  applications  and  outlines  how  the  simulation  results  can  be  applied  to  estimate  how  well  dasa 
would  schedule  these  applicauons. 

5.1.  Simulator  Design  and  Implementation 

The  first  pan  of  this  secnon  outlines  the  set  of  requirenents  that  the  simulator  had  to  meet.  The  other 
parts  describe  the  design  that  was  adopted  and  discuss  significant  implementation  issues. 


5.1.1.  Requirements 

Fundamentally,  the  simulator  must  allow  dasa  to  schedule  a  variety  of  workloads  In  fact,  there  are  a 
number  of  ways  in  which  this  may  be  accomplished.  Therefore,  to  guide  the  simulator  development,  the 
following  general  requirements  were  adopted: 

1.  support  a  variety  of  workloads  conforming  to  the  computational  model  presented  earlier  — 
that  is,  the  simulated  workload  represents  a  real-time  supervisory  control  application,  which 
is  composed  of  a  number  of  activiucs.  each  of  which  may  have  one  or  more  computational 
phases.  The  activities  may  share  resources  as  outlined  previously  in  this  work.  And  ail  of  the 
assumptions  concerning  the  informauon  that  is  available  to  the  scheduler,  such  as  the  amount 
of  computauon  time  to  complete  each  phase,  continue  to  hold  The  set  of  applications  that 
can  be  run  must  be  nch  in  order  to  allow  a  significant  range  of  applications  to  be  explored 

2  offer  standard  statistical  distributions  for  use  by  the  applicauon  —  to  examine  the  behavior  of 
a  scheduler  under  general  conditions,  it  is  often  convenient  to  assume  that  events  occur 
temporally  according  to  a  standard  staustical  distnhuuon.  such  as  a  normal  or  a  Poisson 
distribution 

3.  incorporate  useful  metrics  and  gather  statistics  —  the  metrics  are  intended  to  aid  in  the 
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evaluation  of  scheduler  performance.  For  instance,  the  number  of  time  constraints  satisfied, 
the  number  not  satisfied,  and  the  total  apphcanon-specific  value  accrued  are  all 
straightforward  examples  of  useful  metrics  that  the  simulator  should  support. 

4.  allow  evaluation  of  multiple  scheduling  algorithms  and  resource  management  policies  —  the 
primary  objective  of  the  simulations  is  to  compare  the  performance  of  Dasa  with  that  of  other 
algorithms.  Therefore,  the  simulator  must  accommodate  a  set  of  well-known  scheduling 
algorithms,  including  priority,  deadline,  and  best-effort  schedulers.  In  addition,  since  Dasa 
also  makes  all  of  the  shared  resource  management  decisions,  the  simulator  must  provide 
several  alternative  resource  management  policies,  including  FIFO  and  deadline  queueing  for 
shared  resources  that  are  not  available. 

5.  provide  a  uace  of  the  scheduling  events  and  decisions  made  during  a  simulation  —  this 
information  is  useful  for  at  least  three  reasons:  ( 1 )  it  allows  a  detailed  inspection  of  scheduler 
behavior  to  identify  specific  beneficial  or  detrimental  decisions,  (2)  it  makes  available  raw 
data  that  may  be  processed  to  generate  other  meaningful  statistics  for  any  specific  scheduler, 
and  (3)  during  the  initial  implementation  or  subsequent  modification  of  a  scheduling 
algorithm,  the  event  trace  can  be  examined  by  hand  or  by  machine  to  demonstrate  correct 
behavior. 

6.  possess  the  flexibility  to  adapt  to  changing  requirements  or  to  augment  the  initial  capabilities 
of  the  simulator  —  since  the  simulator  is  used  to  examine  algonthms  under  a  wide  range  of 
circumstances  and  the  appropriate  metrics  are  not  necessarily  known  in  advance,  flexibility  is 
desirable.  In  addition,  if  the  simulator  is  to  be  useful  over  time,  it  will  have  to  be  able  to 
accommodate  new  algorithms  that  will  be  developed,  which  may  or  may  not  resemble  those 
that  already  exist.  By  choosing  internal  interfaces  carefully,  this  is  not  too  demanding  a 
requirement 

The  simulator  developed  meets  all  of  these  requirements,  as  explained  in  the  following  sections. 


5.1.2.  Design 

The  simulator  design  compartmentalized  major  functions  so  that  different  workloads  and  scheduling 
algorithms  could  be  accommodated.  As  shown  in  Figure  5-1,  the  simulator  features  several  independent 
parts: 

1.  a  set  of  shared  resources, 

2.  a  set  of  application  activines,  each  potentially  comprising  a  scqeunce  of  computational  phases 
governed  by  a  time-value  funcuon,  that  may  access  the  shared  resources, 

3.  a  Simulated  Operating  System,  including  an  Integrated  Scheduler  —  that  is,  a  scheduler  that 
not  onl.,  manages  processor  cycles,  but  also  controls  access  to  all  shared  resources,  and 

4.  an  Activity  Generator  that  adds  new  activiues  to  the  application. 

5.1.2. 1.  Activities  and  the  Activity  Generator 

The  Activity  Generator  initiates  the  application  by  creating  the  first  activity  or  activiues.  It  may 
subsequently  create  others  while  the  simulated  application  is  executing. 

The  activiues  comprising  an  application  may  either  be  chosen  from  a  library  of  existing  acuvities  or  they 
may  be  written  specifically  for  the  applicauon.  In  this  wav,  any  activity  can  be  included  in  an  application. 


In  addition,  customized  Activity  Generators  can  be  written  to  initiate  these  acuvities  at  any  time,  obeying 
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Shared  Resources 


Figure  5-1:  Logical  Structure  of  Simulator 

any  constraints  imposed  by  the  actual  application  being  simulated.  Therefore,  this  scheme  will  support 
arbitrary  workloads. 

The  activities  may  mimic  computations  performed  by  real  applications  or  they  may  consume  processor 
cycles  and  access  shared  resources  in  patterns  similar  to  actual  or  potential  applications. 

Whenever  necessary,  an  activity  will  interact  with  the  Simulated  Operating  System  to  acquire  specific 
services.  The  requests  made  to  the  Integrated  Scheduler,  such  as  requesting  the  start  of  a  new 
computational  phase  or  requesting  access  to  a  shared  resource,  are  of  particular  interest  for  this  research. 

5. 1.2.2.  Integrated  Scheduler 

The  interface  to  the  Integrated  Scheduler  conforms  to  the  interface  described  in  Section  2.3.2  for  the 
General  Scheduling  Automaton  Framework,  incoiporanng  scheduling  events  that  are  concerned  with  both 
["■ocessor  cycle  management  and  shared  resource  management. 

Scheduling  algorithms  are  embodied  in  Integrated  Schedulers,  and  different  scheduling  algorithms  can  be 
compared  by  executing  the  same  application  using  various  Integrated  Schedulers. 

The  requests  made  of  the  Integrated  Scheduler  can  naturally  be  divided  into  two  groups:  (1)  those  that 
deal  fundamentally  with  phase  execution  (that  is,  'request-phase,'  'abort-phase,'  'preempt-phase,'  and 
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'resume-phase')  and  (2)  those  that  deal  fundamentally  with  resource  management  (that  is,  request'  and 
’grant’).  Traditionally,  these  two  groups  of  requests  have  been  handled  by  two  different  entities  —  the 
scheduler  and  the  resource  manager,  respectively.  The  simulator  design  at  the  highest  (interface)  level 
hides  that  distinction.  Internally,  however,  for  typical  scheduling  algorithms  requests  are  routed  to  the 
scheduler  or  the  resource  manager. 

On  the  other  hand,  dasa  is  an  integrated  scheduling  algorithm  in  this  sense,  and  so  all  of  the  requests 
originating  from  application  activities  are  directed  to  the  dasa  scheduling  module. 

5.1.3.  Implementation 

Given  a  design,  the  implementation  of  the  simulator  raises  several  new  issues,  including  the  selection  of 
the  tools  to  build  the  simulator,  the  languages  to  be  used,  the  interface  presented  to  the  experimenter,  and 
the  structure  of  the  implementation.  Some  of  the  more  interesting  aspects  of  these  issues  are  discussed  in 
the  following  paragraphs. 

5.1.3. 1.  Approach:  Build  from  Scratch  or  Adapt  an  Existing  Simulator 

There  are  several  different  approaches  that  may  be  used  to  produce  the  simulator  described  above,  and 
selecting  one  of  them  is  the  first  major  implementation  issue  to  be  resolved.  For  example,  the  simulator 
may  be  custom-built  from  scratch.  This  approach  allows  the  simulator  to  be  precisely  tailored  to  meet  the 
goals  of  this  invesugation.  On  the  other  hand,  if  an  existing  simulator  could  be  found  that  is  simdar  in 
purpose  to  the  desired  simulator,  then  it  might  be  modified  to  satisfy  the  present  goals.  Possibly,  this  could 
be  done  quickly  to  generate  useful  results. 

In  fact,  the  approach  used  —  writing  the  simulator  using  SIMSCRIPT  11.5,  a  programming  language 
intended  for  sii  lations  —  falls  between  those  two  extremes.  It  builds  on  previous  work,  while  allowing  a 
large  degree  of  customizauon. 

SIMSCRIPT  provides  a  basic  framework  and  a  number  of  useful  libraries,  including  a  random  number 
generator  and  a  full  complement  of  probability  distributions.  Using  SIMSCRIPT  obviates  the  need  to 
reimplement  and  debug  these  features  for  a  simulator.  In  addition,  simscrjpt  provides  a  programming 
abstracuon  called  a  process  that  is  well-suited  to  model  an  activity.  These  processes  may  control  their  own 
(virtual)  execution,  as  well  as  that  of  other  simscript  processes.  The  code  that  comprises  the  Integrated 
Scheduler  is  executed  by  processes  when  they  initiate  a  scheduling  event.  The  scheduling  algorithm 
dictates  the  resulting  outcome:  either  the  executing  process  will  continue  to  run  or  it  will  block  itself  while 
unblocking  its  successor.  Programming  constructs  exist  to  consume  (virtual)  execution  tune,  and 
simscript  manages  the  advancement  of  virtual  time. 

simscript  also  supports  a  programming  abstraction  called  a  resource  to  embody  shared  resources. 
However,  this  abstraction,  although  providing  the  services  of  a  typical  resource  manager,  was  not  flexible 
for  the  purposes  of  this  work,  where  the  resource  management  decisions  are  more  closely  tied  to  scheduling 
decisions.  Therefore,  some  of  the  resource  features  of  siMSCRiPr  vc.e  superceded  for  these  simulations. 
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The  use  of  a  simulation  programming  language  provided  sufficient  freedom  so  that  the  Integrated 
Scheduler  could  be  implemented  in  the  modular  fashion  described  in  the  design  discussion.  If  an  existing 
simulator  had  been  chosen  as  the  vehicle  for  this  work  rather  than  a  simulation  language,  then  the 
organizational  structure  imposed  by  the  simulator  might  have  precluded  this  possibility 

5. U.2.  Source  of  DASA  Implementation 

The  version  of  the  DASA  scheduling  algorithm  that  w as  included  in  the  simulator  was  adapted  from  the 
procedural  version  of  the  algorithm  presented  in  Section  4.3.3. 1.  A  procedural  version  had  to  be  used, 
since  SIMSCREPT  is  a  procedural  language.  A  straightforward  translation  converted  the  Section  4.3 .3.1 
version  into  a  3IMSCRJPT  version. 

5. 1.3.3.  Single  Scheduler  for  Simulation 

The  simulator  uses  only  a  single  scheduling  algorithm  (and  associated  resource  queueing  discipline)  for  a 
given  simulation  run.  The  simulator  allows  the  arrival  of  new  activities  and  phases  to  be  regenerated 
exactly  for  specified  simulation  runs.  Therefore,  comparing  two  scheduling  algorithms  requires  two 
different  simulation  runs,  one  for  each  of  the  algorithms.  Both  runs  present  idenucal  input  to  the 
scheduling  algorithms.  A  subsequent  examination  of  the  statistical  metrics  and  the  scheduler  performance 
for  each  run  can  then  reveal  which  algonthm  was  more  effective  in  the  simulated  situanon. 

5.1-3.4.  Simulator  Display  Messages 

By  default,  the  simulator  displays  ail  of  the  key  information  regarding  a  simulation  run  to  the 
experimenter.  This  includes  a  nmestamped  message  announcing  the  amvaJ  of  each  new  computational 
phase  that  must  be  scheduled,  along  with  its  time  constraint,  required  execunon  time,  value,  the  number 
and  identity  of  the  shared  resources  that  it  will  require,  and  the  time  micrvaJ  between  each  pair  of  shared 
resource  acquisitions  (in  terms  of  actual  execution  time,  not  real  time).  Nouce  that  although  the  simulator 
prints  information  about  shared  resource  needs  of  a  phase  at  its  outset,  this  lntormauon  is  not  available  to 
the  scheduling  algorithms  when  the  phase  is  initially  presented  to  the  scheduler.  Rather,  each  new  resource 
request  is  made  by  the  phase  at  the  moment  the  resource  is  needed.  Only  at  hat  point  is  the  scheduler 
made  aware  of  the  need  for  that  particular  resource.  The  informauon  about  all  of  a  phase's  resource 
requirements  is  printed  out  when  the  phase  initially  arrives  only  as  a  minor  user  convenience  —  it  allows 
all  of  the  requirements  information  for  the  phase  to  be  presented  together  in  one  place. 

Other  time-stamped  messages  are  displayed  to  the  experimenter  each  time  a  resource  ls  requested  or 
granted  or  a  phase  is  preempted,  resumed,  or  aboned. 

Additionally,  a  simulation  profile  is  pnntcd  that  identifies  the  scheduling  algonthm  and  resource 
queueing  discipline  employed,  the  number  of  shared  resources  available,  and  other  workload  specific 
statistics,  such  as  the  average  interamvaJ  time  between  phases  or  the  average  required  execution  time  for 

each  type  of  phase. 

Finally,  a  statistical  summary  of  the  simulation  is  displaced  at  the  conclusion  of  the  run  It  prints  general 
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statistics  including  the  total  number  of  phases,  the  number  that  met  their  time  constraints,  the  total  value 
represented  by  all  of  the  phases40,  and  the  value  actually  accrued  by  the  scheduler  during  the  simulation. 
Other  statistics  that  are  of  interest  for  a  specific  scheduler  or  workload  can  also  be  displayed  at  the 
conclusion  of  the  simulation. 

All  of  the  messages  displayed  to  the  expenmenter  can  be  redirected  to  a  file  to  record  the  simulation 
results  for  later  analysis.  In  this  case,  the  expenmenter  is  offered  a  summary  cf  the  simulation  in  addition 
to  the  log  file. 

5.13.5.  Modifications 

There  are  a  number  of  modifications  that  may  be  made  to  the  existing  simulator,  and  these  modifications 
can  be  divided  into  two  groups.  First,  there  are  the  changes  that  the  simulator  was  designed  to 
accommodate,  for  instance,  the  addition  of  a  new  scheduling  algonthm  or  a  new  resource  queueing 
discipline.  Second,  there  are  changes  that  may  be  anticipated,  but  -.ere  not  specifically  provided  for  in  the 
simulator.  Extending  the  simulator  to  handle  multiprocessor  scheduling  is  an  example  of  the  latter  type  of 
change. 

Provisions  have  been  made  to  facilitate  the  anticipated  modifications  of  adding  new  scheduling  and 
resource  queueing  policies.  To  add  a  new  policy,  a  set  of  routines  must  be  wntten.  one  routine  to  handle 
each  scheduling  event.  These  routines  are  named  according  to  an  existing  convention.  The  name  of  the 
policy  is  added  to  the  menu  of  policies  available  to  the  expenmenter.  And  finally,  the  new  routines  are 
compiled  and  linked  with  the  existing  simulator. 

Since  the  information  required  or  the  data  structures  used  by  different  scheduling  policies  may  vary 
significantly,  new  data  fields  and  structures  may  be  associated  with  each  activity  or  computational  phase. 
Once  again,  a  naming  convention  has  been  adopted  for  labeling  these  fields  and  structures  to  avoid 
conflicts  with  existing  fields  and  structures. 

The  simulator  has  been  structured  carefully  so  that  modifications  that  could  not  be  anticipated  precisely 
can  be  handled  gracefully.  There  is  no  single  pomt  in  the  simulator  where  all  statistics  may  be  gathered 
and  processed  As  new  statisucs  are  defined,  it  is  likely  that  at  least  some  of  them  will  have  to  be  inserted 
in  code  at  locations  determined  strictly  by  the  scheduling  algonthm  being  examined. 

Preparations  have  been  made  for  some  other  potential  modificanons.  Some  data  structures  have  been 
defined  to  be  more  general  than  necessary  for  the  purpose  at  hand.  For  instance,  the  number  of  application 
processors  that  are  being  scheduled  is  a  vanable  and  there  is  an  array  containing  the  relevant  state  for  each 
of  the  currently  executing  activities.  Of  course  there  is  only  one  cxecuung  activity  under  the  model  being 
investigated  by  this  work.  However,  in  the  future  the  simulator  framework  may  be  able  to  accommodate 


4/>Notice  that  it  may  not  he  possible  to  attain  this  value,  even  with  complete  knowledge  of  the  nhascs  and  their  recjuiremems 
Attaining  this  Lota!  value  may  be  impossible  due  :o  insutt'cicnt  processing  cscies  or  resource  a*  ji  , ability  for  some  portion  of  the 
simulation.  It  does  serve  as  a  clear  upper  bound  on  the  value  that  may  be  obtained  by  any  scheduler 
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multiprocessor  scheduling.  At  that  time,  since  many,  if  not  all.  of  the  scheduling  algorithms  will  have  to  be 
modified  to  handle  muluprocessor  scheduling  and  use  the  simulator's  data  structures  m  a  more  general 
way,  n  is  clear  that  a  great  deal  of  work  is  required  to  make  this  modification  to  the  simulator. 

5.2.  Evaluation  of  DASA  Decisions 

This  section  evaluates  the  decisions  that  DASA  makes  compared  to  the  decisions  made  by  other 
scheduling  algorithms  and  resource  queueing  disciplines.  A  general,  parameterized  workload  is  used  to 
exercise  the  simulator  with  varying  degrees  of  processor  utilization  and  varying  numbers  of  shared 
resources. 

5.2.1.  Methods  of  Evaluation 

The  utility  of  a  scheduling  algorithm  may  be  demonstrated  in  a  number  of  different  ways.  The  following 
paragraphs  deal  with  four  major  approaches  that  correspond  to  four  different  workload  sources. 

5 .2.1.1.  Execute  Existing  Applications 

Perhaps  the  most  compelling  method  would  be  to  employ  the  algorithm  in  an  instrumented,  production 
system  and  compare  the  system  performance  directly  to  its  performance  using  other  alt  nthms.  Using  this 
approach  would  yield  the  most  direct,  relevant  information  regarding  the  applicability  of  the  scheduler  for  a 
given  application 

There  are  three  major  problems  with  this  direct  approach.  First,  although  it  definitely  evaluates  the 
performance  of  the  scheduler  for  a  specific  application,  it  is  not  clear  that  the  information  gathered  can  be 
applied  to  any  other  applications,  and  if  can.  under  what  circumstances.  Since  this  work  is  addressing  a 
general  problem,  the  ability  to  make  statements  that  apply  to  a  general  class  of  applications  is  desirable. 

If  a  wide  range  of  existing  applications  can  be  executed  directly,  this  problem  can  be  eliminated  and  more 
general  results  can  be  derived  However,  since  many  real-time  systems  today  are  still  custom-designed 
w  ith  customized  or  proprietary  operating  systems,  finding  a  large  number  of  real  applications  that  execute 
under  the  same  operating  system  may  be  difficult.  Alternatively,  modifying  the  schedulers  of  several 
different  operating  systems  mav  be  very  difficult  lomstically. 

The  second  major  problem  with  the  direct  approach  is  more  specific  to  the  DASA  algorithm:  the 
algorithm  is  significantly  different  than  those  that  are  used  in  practice  today,  and  it  expects  that  the 
application  will  provide  the  scheduler  with  more  information  than  is  normally  the  case.  (Specifically,  the 
scheduler  should  be  given  an  estimate  of  the  required  computation  time  needed  to  execute  each  dcw 
computational  phase.)  Although  this  information  is  often  known  to  application  designers  and 
implementors,  it  is  not  communicated  tc  the  sclieduler.  As  a  result,  the  interface  to  the  scheduler  that  the 
application  sees  is  different  for  the  DASA  algorithm  than  for  traditional  algorithms  This  requires  that 
every  application  used  must  be  altered  to  provide  that  addiuonal  information  to  the  scheduler,  possibly  long 
after  the  people  who  knew  the  information  are  no  longer  available  or  able  to  provide  it 
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The  final  major  problem  results  from  the  fundamental  difference  in  philosophy  between  traditional 
real-time  systems  and  the  more  dynamic  systems  that  could  employ  a  scheduling  algorithm  such  as  dasa. 
Traditionally,  many  real-time  systems  are  designed  to  be  quite  specialized  with  minimal  overhead  resulting 
from  operating  system  functions.  In  fact,  the  designers  of  these  systems  attempt  to  eliminate  operating 
system  functions  insofar  as  possible,  often  either  reducing  it  to  the  point  where  it  is  more  correctly  termed 
an  executive  or  eliminating  it  entirely  by  having  the  application  perform  all  required  functions. 

In  such  real-time  systems,  not  only  are  operating  system  functions  limited,  but  the  information  supplied  to 
the  operating  system  is  minimal.  For  example,  the  computational  and  timing  requirements  of  a  given  set  of 
activities  may  be  sufficiently  studied  so  that  it  is  possible  to  replace  a  priority  scheduler,  for  example,  with 
a  list  scheduler  or  a  rate-group  scheduler.  Neither  the  list  scheduler  nor  the  rate-group  scheduler  display 
dynamic  behavior  —  at  predetermined  times  they  dispatch  predetermined  acuvities.  All  timing  and 
dependency  considerations  have  already  been  taken  into  account  by  the  system  designers,  and  the  real-time 
system  is  unaware  of  any  of  this  information41. 

As  a  result,  the  implementations  of  real-time  systems  traditionally  distort  the  application's  structure.  For 
example,  often  physical  processes  are  modeled  as  periodic,  even  if  they  are  not,  in  order  to  simplify 
scheduling  and  increase  system  predictability.  Or  shared  data  is  accessed  directly  (without  using  an  access 
control  mechanism  such  as  a  lock)  because  the  acuvites  have  been  designed  and  placed  in  a  sufficiently 
static  schedule  that  it  can  be  demonstrated  that  no  conflicts  can  occur. 

The  philosophy  underlying  dasa  resides  at  the  opposite  end  of  the  spectrum,  in  order  to  handle  dynamic 
applications  today  and  to  effectively  accommodate  application  modifications  tomorrow,  the  system  always 
decides  which  activities  should  be  run,  relying  on  key  information  supplied  by  the  application.  Rather  than 
changing  the  application  in  order  to  restrict  the  information  passed  to  the  operating  system  in  the  hope  of 
reducing  the  run-time  computation  performed  by  the  system  —  rendering  the  application  difficult  to  adapt 
along  the  way  —  the  application  is  encouraged  to  provide  the  system  with  as  much  relevant  information  as 
possible,  thereby  potentially  allowing  the  system  to  make  better  decisions  on  behalf  of  the  application. 

Unfortunately,  this  philosophical  difference  implies  that  the  same  application  designed  and  implemented 
according  each  philosophy  will  produce  very  different  code.  Once  again,  this  limits  the  ability  to  validate 
the  effectiveness  of  dasa  by  simply  using  it  to  schedule  existing  applications.  It  is  quite  possible,  for 
example,  that  an  existing  application  employs  shared  memory  but,  as  mentioned  above,  never  issues  any 
requests  for  access  to  the  shared  resource  because  an  appropriately  restricuve  schedule  makes  it 
unneccessary.  It  is  extremely  unlikely  that  dasa  could  demonstrate  improved  performance  under  such 
constraints. 


4,One  of  the  most  unfortunate  aspects  of  such  systems  becomes  evident  when  '.hey  must  he  moddied  —  perhaps  to  implement  a 
new  function  or  to  add  an  improved  device.  Then  all  of  the  timing  and  dependency  analyses  must  be  performed  again.  In  tact, 
modifying  s  ach  sysf****«  mav  cost  nearly  as  much  as  the  original  implementation. 
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5.2. 1.2.  Modifying  or  Reimplementing  Existing  Applications 

The  preceding  discussion  emphasizes  the  difficulties  involved  in  using  existing  applications  directly  to 
evaluate  dasa. 

Two  of  the  problems  mentioned  above  —  dasa  requiring  more  information  than  is  traditionally  supplied 
to  a  scheduler  and  implementations  that  hide  application  structure  and  information  from  the  operating 
system  —  can  be  addressed  by  modifying  existing  implementanons  or  by  reimplementing  them.  The  new , 
resulting  implementations  could  then  be  executed  using  several  different  schedulers  to  evaluate  the  relative 
effectiveness  of  each  scheduling  algorithm.  However,  in  order  to  justify  any  results  gained  by  this 
approach,  the  new  implementations  would  have  to  be  verified  in  some  manner.  Specifically,  they  would 
have  to  be  demonstrably  equivalent  to  the  original  implementations  in  all  important  respects.  For  real 
applications,  which  are  often  large  and  complex,  this  vague-sounding  requirement  could  be  arbitrarily 
difficult  to  satisfy. 

5.2. 1.3.  Modeling  Existing  Applications 

Creating  skeletal  applications  that  represent  real  applications  reduces  the  amount  of  work  required  to 
produce  each  application,  but  complicates  the  problem  of  proving  that  an  abstracted  application 
corresponds  to  the  real  application  in  all  important  wavs  since,  by  definition,  some  details  of  the  application 
will  have  been  discarded.  Justifying  that  the  selection  of  which  details  should  be  retained  and  which  should 
be  eliminated  or  how  all  or  pan  of  the  application  should  be  modeled  is  once  again  a  vague  requirement 
that  would  have  to  addressed  in  an  ad  hoc  manner  for  each  application  in  all  likelihood. 

As  with  each  of  the  preceding  approaches  to  providing  a  workload  to  use  to  evaluate  the  Dasa  scheduling 
algorithm,  this  method  is  only  capable  of  providing  information  concerning  the  specific  workloads  used. 
There  is  no  guarantee  that  those  applications  are  representative  of  real-ume  supervisory  control  applications 
in  general,  and  these  limitations  must  be  addressed. 

5.2.1. 4.  Simulating  the  Execution  of  a  Parameterized  Application 

The  final  potential  approach  to  evaluate  Dasa,  and  the  one  actually  used,  employs  a  parameterized 
application  or  set  of  applications.  The  execution  of  these  applications  can  then  be  simulated  under  various 
scheduling  algorithms  and  performance  measured.  By  selecting  useful  parameters  and  varying  them  over 
ranges  of  values  more  general  results  can  be  obtained  from  this  workload  than  could  be  drawn  from  a 
specific  set  of  applications. 

Furthermore,  the  simulator  built  for  this  evaluation  can  be  given  an  arbitrary  application  ^workload).  This 
allows  an  experimenter  to  model  a  potential  application  with  any  desired  amount  of  detail,  simulate  the 
application's  execution  using  various  schedulers,  and  decide  whether  the  application  can  benefit  from  the 
use  of  the  Dasa  scheduling  algorithm. 

Short  of  building  an  application  model  for  execution  on  the  simulator,  useful  informauon  is  still  available 
to  allow  people  with  real-time  applications  to  decide  if  dasa  may  be  of  interest  to  them  The  simulation 
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results  that  follow  span  a  significant  portion  of  the  space  of  real-time  supervisory  control  applications, 
based  on  the  variation  of  a  few  key  metrics.  If  necessary,  additional  simulations  could  be  performed  in  the 
future  to  extend  these  results  to  other  regions  of  the  space  or  to  accommodate  new  metrics.  Given  the 
existence  of  these  data,  an  application  designer  or  impjementer  can  either  profile  an  existing  application  or 
create  a  thumbnail  sketch  of  a  new  application  to  determine  where  the  application  lies  in  the  supervisory 
control  space  and  whether  any  benefit  may  accrue  if  the  Dasa  scheduler  is  used. 

This  method  —  simulating  the  execution  of  parameterized  applications  —  was  chosen  to  investigate  the 
utility  of  the  dasa  scheduling  algorithm  because  of  its  ability  to  evaluate  the  algorithm  over  a  wide  range 
of  situations,  rather  than  just  a  few  specific  applications.  At  the  same  time,  it  is  able  to  give  generally 
useful  information  to  real-time  applicatic  designers  and  implemented  for  various  conmditions  and  then 
allows  them  to  investigate  their  application  to  any  desired  degree  of  detail  by  means  of  a  specific  model  for 
then  application.  This  model  can  be  evaluated  using  the  dasa  scheduler,  as  well  as  a  number  of  other 
schedulers  of  general  interest.  Once  again,  new  schedulers  can  be  added  to  ennch  the  simulator  if  needed 
or  desired. 

Thumbnail  sketches  of  real  applications  that  may  benefit  from  the  use  of  the  dasa  scheduler  are 
presented  in  Section  5.3.1. 

5.2.2.  Workload  Selection 

The  workload  used  to  gather  the  simulation  results  that  follow  featured  one  basic  type  of  activity  that  was 
tailored  by  a  number  of  parameters.  In  this  workload,  each  activity  consisted  of  only  a  single  phase.  The 
amval  umes  of  the  activities  could  be  drawn  from  any  of  a  number  of  probability  distributions,  and  the  key 
parameters  that  define  each  distribution  —  such  as  the  mean  for  a  Poisson  or  an  exponential  distribution, 
the  mean  and  standard  deviation  for  a  normal  distribution,  or  the  minimum  and  maximum  for  a  uniform 
distribution  —  were  specified  by  the  experimenter. 

The  time  remaining  until  a  phase's  deadline  is  also  drawn  from  a  specified  probability  distribution  and 
must  always  be  in  the  future.  Once  a  deadline  has  been  selected,  a  fraction  —  drawn  from  a  uniform 
probability  distribution  —  of  the  time  remaining  before  the  deadline  is  specified  as  the  required 
computation  time  of  the  phase.  Once  again,  this  is  always  less  than  or  equal  to  the  amount  of  time 
remaining  until  the  deadline.  Consequently,  any  such  activity  executing  in  a  system  with  no  other  activities 
would  meet  its  time  constraint.  Therefore,  any  time  a  time  constraint  is  not  met.  this  is  due  to  the 
interaction  of  multiple  concurrent  activities. 

Given  the  method  of  generating  new  activities,  their  deadlines,  and  required  computation  times,  it  is 
possible  to  generate  sequences  of  activities  that  may  not  all  be  completed  successfully.  This  is  clear  if  the 
parameters  specify  a  condition  where  the  system  is  overloaded  —  for  instance,  if  the  average  required 
computation  tune  for  an  activity  was  more  than  the  average  interamval  time  between  activities.  However, 
even  in  situations  where,  on  average,  there  is  a  significant  amount  of  idle  time,  there  may  be  transient 
overload  condition.,  due  to  the  probabilistic  nature  of  the  parameter  selection. 
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The  values  that  are  accrued  by  completing  an  activity’s  sole  phase  by  its  deadline  are  also  taken  from  a 
selected  probability  distribution. 

Finally,  the  number  of  shared  resources  is  specified  by  the  experimenter.  If  there  are  shared  resources, 
then  each  activity  probabilistically  determines  how  many  of  these  resources  it  will  require  during  the 
execution  of  its  computational  phase.  It  then  selects  that  number  of  shared  resources  randomly.  The 
resource  requests  are  made  sequentially  with  some  amount  of  processing  time  expended  between  shared 
resource  requests.  The  time  that  passes  between  each  resource  request  is  determined  by  selecting  a  fraction 
of  the  required  computation  time  for  the  phase  that  remains  at  the  time  of  the  previous  resource  request. 
For  each  shared  resource,  the  experimenter  may  specify  the  amount  of  computation  time  that  must  be  spent 
to  return  the  resource  to  a  consistent,  usable  state  in  the  even>  that  the  phase  is  aborted. 

Although  the  resources  required  by  a  phase  are  generated  randomly,  the  actual  resource  requests  are 
ordered  to  avoid  deadlocks  since  that  is  not  a  primary  focus  of  this  work.  This  is  accomplished  by 
associating  each  resource  with  a  unique  key.  where  all  of  the  keys  may  be  ordered.  Requests  are  then  made 
in  increasing  order  of  resource  key  value.  In  this  way.  deadlock  cannot  occur  since  it  is  impossible  for  any 
phase  to  both  hold  a  shared  resource  that  is  needed  by  another  phase  and  to  need  a  shared  resource  already 
held  by  the  same  phase. 

5.2.3.  Examination  of  DASA  Behavior 

A  series  of  experiments  were  performed  to  determine  the  effectiveness  of  the  dasa  scheduling  algorithm 
relative  to  several  other  algorithms  of  interest. 

5.23. 1.  Workload  Parameters  and  Metrics 

These  experiments  used  the  parameterized  workload  described  in  the  previous  section.  In  this  case, 
activities  amved  according  to  a  uniform  probability  distribution.  The  time  between  successive  activity 
arrivals,  which  is  called  the  imerarrival  time,  is  between  zero  and  a  designated  maximum  value.  This 
maximum  value  is  vaned  to  examine  scheduler  behavior  under  different  levels  of  processor  loading. 

The  deadline  for  each  activity  is  also  drawn  from  a  uniform  probability  distribution,  varying  from  zero  to 
200  time  units  (TUs). 

A  straightforward  load  metric  is  employed  for  the  simulations  presented  in  this  section.  For  these 
simulations,  the  expected  activity  interamval  time  is  half  of  the  maximum  activity  interarrival  time. 
Similarly,  the  expected  ume  remaining  until  deadline  is  half  of  the  maximum  time  remaining  until  deadline 
—  in  this  case.  100  TUs.  The  required  computation  time  for  a  given  activity  is  expected  to  be  half  of  the 
time  remaining  until  its  deadline,  or  50  TUs.  The  load  metric,  then,  is  simply  the  expected  time  required  to 
complete  an  activity  divided  by  the  expected  time  between  successive  activity  arrivals. 

By  selecting  maximum  activity  interamval  times  from  800  to  50  TUs,  the  range  of  processor  loads  that 
can  be  examined  extends  from  0.125  (fairly  light  load)  to  2.0  (twice  as  many  cycles  arc  required  as  are 
available,  on  average),  respectively. 
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There  are  two  reasons  for  referring  to  times  in  terms  of  TUs.  rather  than  seconds,  mfdiseconds,  or 
microseconds.  First  of  all,  different  real-time  applications  have  time  constraints  that  cover  a  wide  ranee  of 
absolute  times.  Industrial  supervisory  control  applications  typically  have  time  constraints  that  are 
measured  in  seconds  or  hundreds  of  milliseconds.  Simulators  and  many  military  appiicauons  may  have 
time  constraints  that  are  on  the  order  of  tens  or  hundreds  of  milliseconds.  And  lower-level  control  systems 
can  have  even  tighter  time  constraints.  By  using  TUs,  this  work  is  not  arbitrarily  associated  with  a  single 
class  of  application.  Rather,  it  seems  reasonable  to  expect  that,  in  the  future,  these  scheduling  algorithms 
can  be  applied  to  progressively  more  demanding  real-time  applications  as  processor  speeds  increase  and 
improved  real-time  computer  architectures  are  devised. 

TUs  were  also  used  to  allow  the  results  presented  here  to  be  reevaluated  as  technology  does  change.  In 
particular,  the  overhead  that  is  incurred  by  using  relatively  complex  scheduling  algorithms  can  be 
expressed  in  terms  that  reflect  the  technology  of  the  time,  such  as  the  time  required  to  perform  a 
multiplication  or  division  operation  or  the  time  required  to  sort  a  list.  As  technology  changes,  the  overhead 
changes  as  well. 

This  can  be  contrasted  with  the  real-time  application  being  scheduled.  Often,  the  rime  constraints  that 
must  be  met  are  dictated  by  the  application  itself  —  a  real  world  physical  process  that  is  subject  to  the  laws 
of  physics  for  example.  Improved  computer  technology  does  not  affect  these  rime  constraints,  although  it 
typically  affects  the  application  by  reducing  the  amount  of  processor  time  that  is  required  to  execute  any 
given  piece  of  code.  So  while  the  time  constraints  for  a  specific  physical  process  remain  fixed,  the  absolute 
time  required  to  execute  both  the  application  and  its  scheduling  algorithm  are  reduced  as  technology 
progresses.  This  will  tend  to  increase  the  domain  ui  which  complex  schedulers  may  be  used  in  the  future. 

By  expressing  both  the  tune  constraints  and  the  scheduling  overhead  in  terms  of  TUs,  it  is  possible  to 
determine  what  range  of  time  constraints  are  appropriate  for  a  given  scheduling  algonthm.  To  do  this,  a 
conversion  from  real  time  units  (such  as  milliseconds)  to  TUs  can  be  computed  by  noting  the  rime  required 
to  perform  the  basic  operations  that  dominate  the  scheduling  algonthm  ir  question,  and  therefore  are  most 
responsible  for  its  overhead.  Using  this  conversion  factor,  the  application  time  constraints  can  be  expressed 
in  terms  of  TUs.  Then,  a  simulation  that  directly  mimics  the  application  in  question,  including  scheduling 
overhead,  can  be  run,  or  a  more  general  set  of  simulations  that  take  scheduling  overhead  into  account  can 
be  consulted  to  determine  the  applicability  of  a  given  scheduling  algonthm. 

The  values  associated  with  the  phases  varied  uniformly  from  one  to  ten.  A  minimum  value  of  zero  w  s 
not  used  since  that  could  be  interpreted  as  a  worthless  process,  hence  one  that  need  not  be  scheduled. 

A  fixed  number  of  shared  resources  was  used  for  each  set  of  simulations.  The  results  shown  :n  Figures 
5-2  through  5-7  correspond  to  simulations  employing  zero,  one,  and  five  shared  resources.  Smce  dasa  was 
the  only  algonthm  that  could  abort  specific  phases,  the  undo  times  for  the  shared  resource  were  defined  to 
be  (essentially)  infinite.  In  that  way,  dasa  would  not  schedule  aborts  and  us  bch  :'ior  would  lie  more 
comparable  to  that  of  the  other  algorithms  under  consideration 
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Three  other  scheduling  algorithms  were  chosen  to  compare  with  dasa:  dl,  a  simple  deadline  scheduler, 
SPRi,  a  static  priority  scheduler,  and  LBESA,  Locke's  Best  Effort  Scheduling  Algorithm 

These  algorithms  illustrate  a  number  of  points.  DL  and  SPRi  apply  only  urgency  or  only  importance 
information,  respectively,  while  LBESA  and  Dasa  consider  both  types  of  information.  From  another  point 
of  view,  dl  represents  the  simplest  type  of  deadline  scheduler  —  it  simplies  dispatches  activities  in  order 
of  increasing  deadline.  If  there  is  an  overload,  rather  than  shedding  some  activities,  it  continues  to  schedule 
all  activities  in  deadline  onder.  LBESA  provides  an  advanced  load-shedding  capability  in  a  deadline-based 
scheduler.  And  Dasa  continues  to  extend  this  load-shedding  by  considering  more  activities  for  execution 
than  the  other  algorithms.  Finally.  SPR!  must  be  included  since  it  is  the  algorithm  that  is  actually  used  by  a 
large  number  of  supervisory  control  applications 

Shared  resource  management  for  each  scheduler  (except  dasa)  is  handled  quite  simply:  if  a  requested 
resource  is  available,  it  is  immediately  allocated  to  the  activity  requesting  it.  Otherwise,  the  activity  is 
entered  in  a  FIFO  (first-in,  first-out)  queue  for  that  particular  shared  resource.  When  a  resource  is  freed  at 
the  completion  of  a  computational  phase,  the  first  activity  entered  in  its  waiting  queue  is  removed  from  the 
queue,  given  access  to  the  shared  resource,  and  made  ready  to  run.  The  scheduler  may  subsequently 
resume  its  execution.  (Notice  that  while  activities  are  blocked  waiting  for  a  shared  resource,  they  are  not 
considered  by  any  scheduling  algorithm  other  than  dasa.) 

For  each  combination  of  maximum  activity  interarrival  time,  number  of  shared  resources,  and  scheduling 
algorithm,  a  senes  of  ten  simulations  were  performed.  In  each  simulation,  100  acu vines  were  generated 
and  scheduled. 

The  information  gathered  by  the  simulator  included  a  few  key  metrics:  the  number  of  deadlines  that  were 
met  and  the  total  value  represented  by  all  of  the  activities  and  that  portion  of  the  total  value  that  was 
actually  accrued  by  the  application  executing  under  a  given  scheduling  algonthm.  These  were  reduced  to 
percentages  indicating  the  fraction  of  deadlines  that  were  met  and  the  fraction  of  the  available  value  that 
was  obtained. 

In  addition,  the  simulator  generated  an  event  log  that  could  be  examined  in  order  to  analyze  individual 
situations  and  decisions  made  by  various  scheduling  algorithms. 

5.2J.2.  Scheduler  Performance  Analysis 

The  simulations  described  in  the  previous  section  were  performed  and  the  results  arc  shown  in  Figures 
5-2  through  5-7. 

Figures  5-2  through  5-4  show  the  percentage  of  total  available  value  that  was  actually  obtained  and  the 
percentage  all  deadlines  that  were  actually  met  when  there  were  zero,  one.  and  five  shared  resources, 
respectively,  under  a  variety  of  processor  loads  In  these  figures,  the  geornetne  mean  for  each  scheduling 
algorithm's  performance  is  plotted  as  a  function  of  average  processor  load 
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Figure  5-3:  Average  Scheduler  Performance  with  One  Shared  Resource 
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Figure  5-4:  Average  Scheduler  Periormancc  with  Five  Shared  Resources 
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All  of  the  scheduling  algorithms  perform  well  under  small  loads.  There  are  sufficient  processing  cycles 
that  the  exact  scheduling  algorithm  makes  little  difference.  As  processor  load  increases,  all  of  the 
algorithms  become  less  effective  and  the  differences  among  them  become  more  apparent  Of  course,  for 
loads  greater  than  1.0.  it  is  impossible  to  complete  all  of  the  acnvities  on  ome  —  there  are  simply  not 
enough  processor  cycles  to  satisfy  demand  Even  for  loads  that  are  less  than  1.0.  there  are  usually  intervals 
that  represent  momentary  overloads  —  that  is,  short  intervals  of  time  where  it  is  not  possible  to  complete 
all  of  the  activities  on  time  —  due  to  the  probabilistic  nature  of  the  workload.  (Consequently,  obtaining 
100%  of  the  available  value  or  meeting  100%  of  the  deadlines  for  a  simulation  is  often  impossible 
However,  it  serves  as  an  absolute  upper  bound  on  the  performance  of  the  scheduling  algorithms.) 

DL  drops  most  rapidly  in  performance,  primarily  due  to  the  fact  that  it  does  not  shed  load.  This  was  done 
intentionally  to  show  an  extreme  behavior  of  deadline -based  scheduling  lbesa  and  dasa  represent 
another  extreme  since  they  generate  schedules  that  are  deadline-ordered  and  only  depart  from  deadline- 
ordered  schedules  when  overloads  are  detected.  As  shown  in  Figure  5-2.  even  when  there  are  sufficient 
processor  cycles,  on  average,  it  is  still  difficult  to  meet  many  deadlines  using  the  DL  scheduler. 

DL  does  not  degrade  appreciably  with  different  numbers  of  shared  resources  because  the  overload 
behavior  just  described  dominates  its  behavior. 

SPRJ  degrades  smoothly  as  load  increases.  As  more  shared  resources  are  added,  increasing  the  interaction 
of  the  activities,  its  performance  decreases  more  rapidly  as  a  function  of  load. 

lbesa  exhibits  a  few  noteworthy  tendencies.  First  of  all.  when  there  are  no  shared  resources,  it  typically 
meets  more  deadlines  than  sprl  while  accruing  less  value.  This  is  partially  a  consequence  of  its  time- 
driven  orientation  compared  to  the  value-driven  nature  of  SPRL  Like  sprj.  it  also  displays  graceful 
degradation  as  load  increases  and  there  are  no  shared  resources. 

When  there  are  shared  resources,  lbesa  performs  quite  differently.  It  typically  performs  much  worse 
than  any  of  the  other  algorithms  at  relatively  low  processor  loads  This  results  from  a  particularly 
unfortunate  interaction  between  the  scheduler  and  the  shared  resource  manager. 

As  was  pointed  out  earlier,  the  actioas  of  the  shared  resource  manager  constitute  indirect  scheduling 
decisions  by  blocking  activities  that  had  been  executing  and  subsequently  determining  the  order  in  which 
they  are  again  made  ready  (and  become  visible  to  the  scheduler) 

The  problem  with  lbesa  and  the  resource  manager  arises  w  hen  an  acuvity  requests  a  shared  resource  that 
has  previously  been  allocated  to  another  activity.  The  requesting  activity  is  then  blocked  and  placed  in  the 
FIFO  queue  for  the  resource.  Later,  the  resource  is  allocated  to  the  activity  and  the  activity  is  added  to  the 
ready  list  for  the  scheduler.  However,  if  the  activity  nevers  completes  its  current  phase  —  either  because 
there  is  insufficient  time  to  complete  it  by  its  deadline  or  its  value  density  is  too  low  to  prevent  it  from 
being  shed  during  an  overload  —  it  will  hold  the  resource  indefinitely.  Therefore,  all  subsequent  activities 
that  require  access  to  the  reource  will  fail  to  meet  their  deadlines.  Of  course,  this  scenario  does  not  result 
every  time  an  allocated  shared  resource  is  requested  But,  it  docs  happen  occasionally  even  at  low- 
processor  loads. 
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DL  and  SPR]  are  not  susceptible  to  this  particular  interaction  because  they  don't  shed  load.  They 
eventually  execute  every  activity  that  arrives.  Consequently,  any  acuvitv  that  acquires  a  shared  resource 
will  eventually  complete  execution  of  its  current  phase  and  release  the  resource.  Only  algorithms  that  shed 
load  must  be  concerned  about  the  fact  that  activities  that  are  shed  may  be  holding  shared  resources42. 

DASA  also  degrades  gracefully  as  processor  load  increases,  managing  to  accrue  more  value  and  meet  more 
deadlines  then  any  of  the  other  algorithms  in  these  simulations.  Even  with  a  load  of  2.0,  dasa  obtains,  on 
average,  over  55  percent  of  the  available  value  —  over  25  percent  more  value  than  any  of  the  other 
algorithms. 

Dasa  is  not  subject  to  an  unfortunate  interaction  with  the  shared  resource  manager  since  it  manages  the 
resources  itself.  Like  LoESA,  it  will  recognize  that  some  activities  holding  shared  resources  cannot  meet 
their  deadlines  and  so  will  not  schedule  them.  However,  unlike  lbesa,  dasa  will  realize  when  another 
activity  that  can  still  meet  its  deadline  needs  the  previously  allocated  resource  and  will  attempt  to  execute 
the  activity  holding  the  resource  in  order  to  enable  continued  progress  by  the  application.  In  this  way, 
processor  cycles  are  not  consumed  to  free  allocated  resources  unless  there  is  an  immediate  need  for  the 
resources.  This  is  in  keeping  with  the  general  philosophy  that  the  system  should  always  perform  the 
activities  that  will  be  most  valuable  to  the  system  at  any  time  —  processor  cycles  are  not  expended  to  free 
allocated  resources  unless  there  is  value  in  doing  so. 

In  Section  4. 3. 2.4,  it  was  shown  that  dasa  could  accrue  more  value  than  lbesa  in  during  overloads 
because  lbesa  could  shed  some  activities  unnecessarily.  However,  it  is  impossible  to  prove  analytically 
how  often  the  necessary  overload  conditions  will  a rise  for  an  application  The  simulation  results  presented 
in  Figure  5-2  show  that  this  effect  is  quite  pronounced  under  overload  conditions  —  with  a  2.0  load,  dasa 
obtains,  on  average,  about  35  percent  more  value  and  meets  about  30  percent  more  deadlines  than  lbesa. 
(Since  there  are  no  shared  resources  for  these  simulations,  the  interaction  of  lbesa  and  the  shared  resource 
manager  has  no  effect  on  the  simulation  results.  Under  low  loads,  dasa  and  lbesa  are  expected  to  perform 
similarly,  and  under  high  loads  their  differences  should  be  due  to  differences  in  load  shedding.) 

Figures  5-5  through  5-7  display  more  information  concerning  the  simulations  described  earlier.  Where 
Figures  5-2  through  5-4  plotted  the  geometric  mean  for  each  scheduling  algonthm  under  various  loads  with 
differing  numbers  of  shared  resources.  Figures  5-5  through  5-7  show  ihe  range  of  values  obtained  and 
deadlines  met  in  each  of  these  situations.  In  addition,  the  arithmetic  mean  is  shown  as  a  box  placed  along 
the  range;  the  geometric  mean  is  shown  as  a  star,  and  the  harmonic  mean  is  shown  as  a  diamond.  As 
always  for  nontrivial  data  sets,  the  arithmetic  mean  is  greater  than  the  geometric  mean,  which  is  greater 
than  the  harmonic  mean,  for  each  case.  However,  the  means  are  often  so  close  that  their  symbols  appear 
superimposed  in  the  figures. 


<2U8ESA  has  been  modified  to  execute  in  the  Alpha  Operating  System.  Several  adaptations  were  necessary  to  use  the  algonthm  in 
Alpha,  ^.c  Alpha  programming  model  treats  unsatisfied  lime  constraints  and  communication  failures,  among  others,  as  exceptions. 
When  an  exception  is  encountered,  an  associated  handler  is  executed.  This  handler  restores  system  data  structures  to  acceptable  states 
and  offers  the  application  programmer  the  opportunity  to  do  the  same  for  application  data  structures  and  activity  slate.  This  offers  the 
opportunity  to  free  shared  resources  in  practice  after  an  unsatisfied  nme  constraint,  even  though  the  lbf^a  model  does  not  address 
shared  resources. 
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Varying  Load,  No  Resources 


Varying  Load,  No  Resources 


Figure  5-5:  Scheduler  Performance  Range  with  No  Shared  Resources 
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Varying  Load,  One  Shared  Resource 


Varying  Load,  One  Shared  Resource 


Figure  5-6:  Scheduler  Performance  Range  with  One  Shared  Resource 
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Varying  Load,  Five  Shared  Resources 


Varying  Load,  Five  Shared  Resources 


Figure  5-7:  Scheduler  Performance  Range  with  Five  Shared  Resources 
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Once  again,  at  low  loads  with  no  shared  resources,  all  of  the  scheduling  algorithms  perform  well, 
displaying  a  fairly  small  vananon  in  performance  over  mulnple  simulations.  The  introduction  of  shared 
resources  has  a  marked  effect  on  lbesa's  performance,  even  at  low  loads  —  it  may  perform  as  well  as  the 
others  or  it  may  perform  much  worse  (for  reasons  that  were  explained  earlier  in  this  section). 

As  load  increases,  each  algorithm  displays  more  variability  across  multiple  simulations.  Like  LBESa  at 
lower  loads,  DL’s  performance  falls  off  sharply  as  load  increases  with  a  great  deal  of  variability. 

At  higher  loads,  Dasa’s  performance  is  superior  to  the  others.  In  fact,  in  several  cases,  the  worst 
performance  by  dasa  for  a  given  set  of  simulations  is  superior  to  the  best  performance  of  any  of  the  other 
algorithms.  Furthermore,  looking  at  individual  simulations.  Dasa  always  outperforms  the  others  at  high 
loads. 

5J.  Interpreting  Simulation  Results  for  Specific  Applications 

To  complete  this  chapter,  this  section  looks  at  a  few  supervisory  control  applications  for  which  dasa  may 
be  useful.  They  are  indicative  of  some  types  of  applications  that  might  be  of  interest,  but  do  not  touch  on 
many  other  possibilities,  such  as  simulators  and  military  platform  managerr 

Each  application  is  outlined  briefly,  indicating  roughly  the  types  of  time  constraints  involved,  the 
processing  requirements,  and  the  number  and  types  of  shared  resources.  Application  details  are  provided  to 
explain  how  supervisory  control  system  requirements  are  shaped  by  the  physical  world.  However,  the 
descriptions  are  necessarily  bnef  since  too  many  details  would  obscure  important  information  concerning 
application  structure  and  requirements. 

5.3.1.  Some  Interesting  Applications 

This  section  presents  thumbnail  sketches  of  two  real-world  applications  that  may  benefit  from  the  use  of 
the  dasa  scheduler. 

These  applications  are  discussed  for  two  reasons.  First  of  all,  they  give  a  flavor  of  some  other 
applications  (in  addition  to  those  presented  in  Chapter  l ).  The  characteristics  that  make  these  applications 
particularly  amenable  to  the  use  of  the  Dasa  scheduling  algorithm  are  noted  where  appropriate. 

Secondly,  they  offer  a  chance  to  use  real  applications  to  study  how  the  metrics  used  for  the  simulation 
results  can  be  initially  estimated  from  a  knowledge  of  the  application.  Of  course,  the  applications  are 
presented  briefly  here  and  much  better  statistics  could  be  gathered  more  carefully  by  actual  real-time 
system  professionals  who  were  interested  in  investigaung  alternate  scheduling  algorithms. 
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5.3. 1.1.  Telephone  Switching 

The  telephone  company  typically  creates  a  dedicated  circuit  to  handle  each  telephone  call.  This  circuit  is 
actually  composed  of  a  number  of  shorter  circuits  that  are  connected  by  computer-controlled  switches. 
These  switches  handle  the  routing  of  the  call  from  the  originator  to  the  receiver. 

Each  time  a  call  is  initiated,  a  circuit  must  be  set  up  to  complete  the  call.  At  each  routing  switch  along  the 
way.  signals  must  be  sent  and  acknowledged  in  a  moderately  short  period  of  time  —  often  on  the  order  of  a 
second. 


Because  there  is  no  way  to  associate  a  pnonty  with  a  call,  it  is  generally  impossible  to  distinguish  urgent 
calls  from  less  important  calls.  Therefore,  a  certain  portion  of  the  circuit  capacity  of  the  phone  company  is 
often  held  in  reserve,  even  during  periods  of  peak  demand,  in  order  to  service  critical  calls  in  case  of  an 
emergency.  As  a  result,  this  capacity  is  unavailable  for  general  service  and  is  wasted  (in  a  sense)  when 
there  are  no  emergency  calls. 

This  application  could  almost  certainly  benefit  by  using  a  scheduling  algorithm  such  as  dasa.  For 
instance,  the  application  could  be  restructured  so  that  each  call  had  an  associated  priority.  As  indicated 
earlier,  each  call  also  has  a  series  of  time  constraints  that  must  be  met  in  order  to  properly  control  the 
switches  needed  to  complete  the  call.  So  the  simple  time-value  functions  used  in  this  research  can  be 
applied  directly  in  this  application  to  capture  both  the  importance  and  the  urgency  of  each  call  in  the 
system.  So  an  activity  can  be  assigned  to  handle  each  call. 

The  shared  resources  in  the  system  are  the  circuits  and  switch  connections.  To  complete  a  call  a  number 
of  these  shared  resources  must  be  acquired.  At  the  completion  of  the  call,  they  may  be  released. 

In  addiuon,  no  circuits  must  be  reserved  exclusively  for  emergency  calls.  Therefore,  the  overall  capacity 
for  telephone  calls  available  to  telephone  company  subscribers  can  be  increased.  This  is  due  to  the 
behavior  of  dasa  under  overload  conditions. 


Under  normal  conditions,  where  there  are  sufficient  resources  exist  to  satisfy  demands  in  a  timely 
manner,  all  of  the  calls  are  completed  and  activities  are  scheduled  essentially  in  order  of  their  respective 
deadlines  regardless  of  their  relative  priorities.  When  demand  exceeds  the  supply  of  shared  resources  (even 
within  a  single  switch),  some  calls  cannot  be  completed.  In  that  case,  a  call's  pnonty  would  be  considered 
when  making  scheduling  decisions  so  that  more  important  calls  receive  shared  resources  at  the  expense  of 
less  important  calls.  In  fact,  Dasa  would  abort  less  important  calls  that  are  holding  shared  resources  in 
order  to  free  circuits  and  switches  to  complete  new,  higher  priority  calls43. 


4,WKi!c  aborting  any  calls  is  unfortunate  —  they  represent  a  disruption  of  service  to  customers  —  these  aborts  will  not  email 
serious  damage  More  likely,  an  abort  will  result  in  a  disgruntled  caller  and  caliee.  And  since  humans  aje  involved  in  virtually  every 
calL  they  are  capable  of  taking  appropriate  steps  following  an  aborted  call  —  perhaps  redialing  immediately  maybe  waiting  awhile 
before  redialing,  or  maybe  just  waiting  for  a  more  opportune  time  if  the  call  was  not  at  all  urgent.  The  actual  abort  processing  presents 
the  telephone  company  with  an  opportunity  to  make  the  abort  in  a  fairly  painless  way.  As  the  connection  is  broken,  each  party  in  the 
call  could  be  informed  that  the  call  had  to  be  aborted  in  favor  of  an  urgent  call  Furthermore,  the  effected  parties  could  be  given  some 
compensation  for  their  inconvenience  such  as  an  account  credit  or  a  free  call  al  a  later  date.  The  processing  requirements  for  this  type 
of  abort  processing  could  be  associated  with  the  acquisition  of  circuits  and  switch  connections  and  is  accommodated  by  the  abort 
model  for  this  research,  which  allows  a  resource -dependent  amount  of  processing  time  to  be  reserved  in  case  an  abort  occurs 
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The  transition  from  overload  to  normal  (non-overload)  processing  would  be  as  graceful  as  the 
transformation  into  the  overload  case,  where  most  panics  are  Likely  to  be  uneffected  while  emergency 
traffic  acquires  the  resources  it  requires. 

Without  presenting  them  here,  there  are  a  wealth  of  statistics  available  to  the  telephone  companies 
describing  the  frequency  at  which  calls  arrive  throughout  a  day,  profiling  various  days  t  weekends, 
weekdays.  Mother's  Day,  and  so  on),  the  computational  requirements  to  route  a  call  and  to  make  the 
necessary  connections,  and  the  numbers  and  types  of  the  shared  resources  in  the  system  (circuits,  switch 
connections,  logs,  and  databases  for  instance).  These  statistics  would  be  used  to  consult  the  simulation 
charts  presented  in  this  chapter  or  others  derived  for  this  specific  application. 

5_3. 1.2.  Process  Control:  A  Steel  Mill 

A  steel  mill  provides  a  number  of  supervisory  control  applications  that  could  benefit  from  advantageous 
real-time  scheduling.  This  section  returns  to  the  example  that  was  originally  introduced  in  Sections  1.1.2 
and  1.4,  focusing  on  a  computer  system  that  controls  a  number  of  furnaces  supplying  steel  with  specific 
compositions  to  a  pair  of  conunuous  casters,  which  cast  the  molten  steel  into  slabs. 

First,  consider  the  rime  constraints  for  this  application. 

Each  caster  continuously  produces  a  slab  that  is  cut  to  specified  lengths  to  fill  orders.  The  slab  lengths 
typically  vary  between  twenty  and  forty  feet,  and  each  ume  a  new  slab  is  cut.  a  new  slab  record  has  to  be 
generated  and  stored. 

The  caster  speed  varies  —  if  it  moves  too  quickly,  the  metal  will  not  have  solidified  sufficiently  by  the 
time  it  emerges  from  the  caster,  if  it  moves  too  slowly,  productivity  will  be  unnecessanly  low.  The  caster 
is  operated  at  the  maximum  speed  at  which  solid  steel  can  be  produced.  This  speed  is  determined  by  the 
temperature  and  chemistry  of  the  steel  being  cast,  the  water  temperature  and  spray  rates  of  cooling  nozzles 
located  along  the  length  of  the  caster,  and  several  other  factors.  Typically,  a  new  foot  of  steel  emerges 
from  the  caster  every  six  to  twelve  seconds. 

Each  time  a  new  foot  of  steel  is  cast,  a  record  must  be  created  to  document  the  chemistry  of  the  foot  and 
other  information  that  is  used  to  track  the  metal  through  the  mill.  If  this  information  is  lost  or  is  not 
recorded  on  time,  the  chemistry  of  the  slab  cannot  be  adequately  certified  for  customers  with  strict  product 
quality  requirements,  and  the  slab  cannot  be  sold  to  them.  The  processing  that  occurs  as  each  foot  of  steel 
is  cast  is  quite  complex  and  requires  a  second  or  two  of  processing  time. 

The  furnace  has  fewer  tight  time  constraints  than  the  caster.  The  tumaccs  produce  steel  in  units  called 
"heats.''  A  heat  typically  requires  between  thirty  and  forty-five  minutes  to  produce.  During  that  ume.  the 
chemistry  of  the  steel  is  calculated  several  times  by  a  complex  analytical  model.  The  chemistry  is  also 
measured  directly  by  a  chemistry  laboratory.  Even  after  the  heat  is  produced  the  steel's  composition  may 
be  adjusted  at  a  liquid  metallurgy  facility.  Near  the  conclusion  of  a  heat,  oxygen  is  blown  through  the 
molten  metal  to  reduce  the  carbon  content  of  the  steel.  It  is  important  to  produce  steel  with  a  fairly  precise 
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carbon  content  because  of  the  extent  to  which  carbon  content  affects  the  physical  properties  of  steel.  The 
oxygen  is  blown  through  the  steel  under  the  direction  of  the  supervisory  control  computer,  and  it  must  be 
shut  off  at  a  precise  time  after  it  has  started.  This  time  is  determined  by  the  supervisory  control  computer 
based  on  the  analytic  mode!  and  the  measured  chemical  compostion  of  the  steel.  Missing  this  deadline  can 
be  costly. 

Next,  consider  the  shared  resources  in  this  example. 

Each  heat  is  tracked  as  it  makes  its  way  through  the  mill  from  the  furnace  to  the  caster  and  beyond.  The 
primary  database  for  this  tracking  is  called  the  heat  log  An  entry  in  the  heat  log  is  initially  made  as  the 
furnace  begins  a  heat.  The  record  may  be  modified  by  the  liquid  metallurgy  facility  or  a  holding  station  or 
even  one  of  the  casters.  Information  arrives  for  the  heat  log  asynchronously.  There  is  typically,  for 
example,  no  guaranteed  response  time  for  the  chemistry  laboratory  to  return  an  analysis;  heats  are  not 
produced  periodically,  although  they  are  produced  regularly;  and  the  order  in  which  heats  are  cast  can 
change  on  very  short  notice. 

There  are  a  number  of  other  databases  in  this  example.  All  are  shared  among  muluple  activities. 
Usually,  most  of  these  activities  are  cooperating  to  produce  steel,  while  others  perform  maintenance  tasks, 
such  as  calculating  the  lifetime  of  furnace  linings  and  cutting  torches  or  monitoring  the  inventory  of  scrap 
metal  and  critical  ingredients.  All  of  these  activities  require  access  to  the  databases 

Often  activities  cooperate  to  carry  out  the  various  application  tasks.  These  tasks,  perhaps  fifty  or  sixty  in 
number,  make  extensive  use  of  signals  to  communicate  with  one  another.  Typically,  a  number  of  activities 
cannot  proceed  until  one  or  more  other  activities  have  properly  gathered  and  prepared  the  necessary  data  or 
until  some  external  event  has  occurred.  Signals  are  an  efficient  communication  mechanism  in  such 
systems. 

Devices  are  also  shared  in  this  application.  The  communication  channels  to  the  lower-level  process 
control  computers,  to  the  higher-level  production  control  computers,  and  to  human  operators  that  oversee 
production  are  of  particular  interest. 

Notice  that  this  application  fits  the  mode!  outlined  in  this  thesis.  The  mill  exists  to  make  steel,  which  has 
a  very  definite  value.  It  is  possible  to  place  corresponding  values  on  the  steps  taken  to  produce  tlie  steel, 
making  the  use  of  time-value  functions  feasible  for  this  application 

Furthermore,  it  is  a  supervisory  control  application  with  deadlines  that  are  on  the  order  of  seconds.  All  of 
the  component  physical  processes  proceed  asynchronously,  and  the  processor  utilization  is  sufficiently  high 
that  some  transient  overloads  will  occur. 

Of  course,  failures  in  the  system  or  alarm  conditions  from  the  lower-level  process  control  computers  can 
also  add  unanticipated  load  to  the  supervisory  control  system  for  a  generally  unspecified  length  of  time  In 
addition,  queries  and  commands  from  human  operators  also  contribute  to  the  processing  load  They  arrive 
asynchronously  and  typically  must  be  serviced  within  a  matter  of  seconds  Overloads  arc  not  unusual  in 
these  systems. 
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Chapter  6 

Related  Work  and  Current  Practice 


There  has  been  a  great  deal  of  research  done  on  scheduling,  in  general,  and  scheduling  for  real-time 
systems,  in  particular,  through  the  years  This  chapter  will  attempt  to  put  this  thesis  work  in  its  proper 
place  within  this  overall  context. 

A  wide  variety  of  scheduling  algorithms  have  been  devised  and  analyzed  through  the  years  for  computers. 
Most  of  the  basic  scheduling  algorithms  are  covered  in  text  books  on  scheduling  [Baker  74,  French  82]  or 
on  operating  systems  [Janson  85.  Peterson  85].  Each  algorithm  possesses  certain  properties  that 
differentiate  it  from  others.  For  instance,  round-robin  is  fair,  while  shortest  processing  time  first  maximizes 
throughput.  However,  many  of  these  properties  have  no  value  in  real-time  systems.  Nonetheless,  these 
texts  do  contain  scheduling  algorithms  that  are  useful  in  real-time  systems. 

Real-time  scheduling  algorithms  can  be  categonzed  in  a  number  of  ways.  For  now.  the  algorithms  will 
be  divided  into  two  groups:  those  that  are  pnonty-based  and  those  that  are  deadline-based. 

6.1.  Priority-Based  Scheduling 

Most  of  the  real-time  systems  currently  m  service  employ  a  static  priority  scheduler  of  one  type  or 
another.  In  these  systems,  component  activities  are  assigned  siauc  pnonties.  and  the  systems  are  tuned  so 
that  they  will  typically  meet  their  time  constraints.  There  is  also  a  large  body  of  literature  that  has 
investigated  prionty-based  scheduling  algorithms  beyond  this  current  practice.  In  [Liu  73],  a  method  for 
static  priority  assignment  was  presented  for  penodic  real-time  activities.  The  scheduling  discipline  that  has 
grown  from  this  work  is  called  rate  monotonic  scheduling.  This  basic  approach  has  been  elaborated  and 
expanded  upon  since  (e  g..  [Sha  86]),  but  the  applications  for  which  it  is  intended  are  always  those  where 
most,  if  not  all,  of  the  activities  are  periodic,  and  where  the  penodic  activities  are  always  the  most 
important  activiues  in  the  system.  While  there  are  systems  that  fit  this  disenption.  the  family  of 
supervisory  control  systems  that  are  of  interest  in  this  thesis  do  not.  Also,  none  of  the  rate  monotonic 
scheduling  algonthms  deal  directly  with  the  problem  of  scheduling  a  set  of  dependent  activities. 

A  second  class  of  priority-based  scheduling  algorithms  has  dealt  explicitly  with  some  of  the  scheduling 
difficulties  that  anse  as  a  result  of  the  dynamic  interaction  of  activities.  Some  operating  systems  (e  g., 
VMS  [KB  84])  implement  pnontv  adjustment  schemes  to  refine  the  simple  static  pnonty  model,  and  other 
schemes  have  been  proposed  in  the  literature  as  well  (  [Sha  87]).  All  of  these  schemes  address  problems  in 
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which  a  lower  priority  activity  that  shares  a  resource  with  a  higher  priority  activity  can  block  the  higher 
priority  activity  for  an  arbitrarily  long  time.  The  solution,  roughly  speaking,  allows  the  lower  priority 
activity  to  assume  a  higher  priority  for  at  least  long  enough  to  complete  its  access  to  the  shared  resource, 
thereby  allowing  the  higher  priority  activity  to  resume.  This  approach  does  solve  some  problems  that  are 
associated  with  simple  priority-based  scheduling  algorithms,  but  it  does  not  come  to  gnps  with  the 
fundamental  shortcoming  of  all  of  the  pnonty-based  schemes:  priorities  are  unable  to  adequately  capture 
the  critical  scheduling  information  for  activiues.  Specifically,  an  individual  activity's  importance  to  the 
overall  application  and  its’  urgency  are  two  independent  factors:  an  acuvity  is  not  urgent  just  because  it  is 
very  important,  and  it  is  not  important  just  because  it  is  urgent  This  distincuon  is  lost  in  static  prionty 
scheduling  schemes  where  both  importance  and  urgency  must  be  reflected  in  a  single  quantity,  the 
activity’s  prionty. 


6.2.  Deadline-Based  Scheduling 

The  second  group  of  real-time  scheduling  algonthms  to  be  dealt  with  are  the  deadline-based  algonthms'14. 
These  algonthms  seem  well-suited  for  real-time  systems  since  they  explicitly  take  into  account  an  acovitv 's 
time  constraints,  and  they  do  not  typically  require  that  all  activities  be  penodic.  Deadline  schedulers  have 
been  in  use  in  operating  systems  at  least  since  the  1960s,  and  [Liu  73]  demonstrated  the  optimality  of 
deadline  scheduling  under  one  computational  model.  Unfortunately,  the  basic  deadline  scheduling 
algonihm  becomes  unstable  whenever  an  overload  occurs;  it  acts  to  minimize  the  maximum  job  lateness 
and  maximum  job  tardiness!  [Conway  67]).  This  may  be  the  desired  action,  but  often  it  is  not. 
Consequently,  a  great  deal  of  work  has  been  done  to  modify  the  behavior  of  deadline  scheduling  in 
overload  situations.  Some  work  that  does  not  consider  dependency  requirements  includes:  [Martel  82], 
which  presents  an  algorithm  that  will  complete  all  of  the  (independent)  activities  while  minimizing  the 
maximum  lateness  of  any  individual  acuvity;  [Moore  68],  which  uses  a  scheme  that  also  completes  all  of 
the  independent  activities  while  minimizing  the  maximum  deferral  cost  associated  with  any  acuvity;  and 
[Locke  86],  which  docs  not  necessarily  execute  all  of  the  activities,  but  docs  attempt  to  maximize  the  value 
acquired  by  compleung  those  that  are  executed.  In  each  case,  these  schemes  do  not  consider  dependencies, 
but  do  address  the  issue  of  overload  handling,  which  is  one  of  the  main  interests  of  this  thesis. 

Historically,  there  has  been  a  great  deal  of  emphasis  placed  on  being  able  to  guarantee  that  deadlines  can 
be  met.  In  simple  systems  that  have  been  built,  this  has  been  possible,  or  has.  at  least,  appeared  to  be 
possible.  As  systems  have  grown,  this  has  become  increasingly  more  difficult  to  do  In  large,  dynamic 
systems,  it  is  rapidly  becoming  impossible.  Nonetheless,  guaranteeing  that  deadlines  can  be  met  is  often 
considered  a  prime  requirement  for  so  called  hard  real-time  systems,  and  much  -"ork  has  been  done  in  this 
area.  (In  a  hard  real-time  system,  missing  even  a  single  deadline  means  that  the  enure  system  has  failed  ) 
For  simple  systems  where  all  of  the  activities  need  to  be  scheduled  periodically  and  have  fixed  execution 
time  requirements.  [Liu  731  and  others  allow  an  off-line  analysis  to  guarantee  the  schcduiabibtv  of  a  set  of 
activities  under  certain  assumptions.  In  more  dynamic  cases  where  less  emphases  is  placed  on  penodic 


[lr\  some  of  the  management  and  operations  research  literature,  deadlines  are  referred  to  as  due  dates. 
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activities,  work  similar  to  [Ramamntham  84]  attempts  to  provide  the  same  type  of  guarantee.  However,  it 
is  not  obvious  that  attempting  to  offer  true  guarantees  is  wise  in  a  dynamic  system  because  honoring  a 
guarantee  may  result  in  an  inability  to  schedule  a  new  activity  that  is  clearly  more  important  and  more 
urgent  than  the  previously  guaranteed  activity.  In  addition,  the  guarantees  that  are  offered  are  not  absolute. 
Receiving  a  guarantee  indicates  that  adequate  resources  have  been  reserved  to  complete  an  activity  by  the 
desired  time.  If  resources  are  subsequently  lost  —  due  to  a  processor  or  a  power  failure,  for  example  — 
the  guarantees  made  cannot  always  be  met. 

There  is  also  a  body  of  literature  that  explicitly  deals  with  dependencies  in  deadline-based  scheduling 
algorithms.  It  should  be  noted  that  what  is  termed  a  dependency  considerauon  in  this  thesis  encompasses 
both  the  notion  of  a  precedence  constraint  (e  g.,  aenvity  At  must  complete  before  either  activity  .4,  may 
begin)  and  the  notion  of  a  resource  requirement  (e  g.,  activity  Aj  requires  exclusive  use  of  resource  R  for 
lime  T  dunng  its  execution).  In  the  literature,  these  two  types  of  dependencies  are  often  treated  separately. 
[Blazewicz  77],  for  instance,  deals  only  with  precedence  constraints  and  provides  an  algonthm  that  will 
allow  activities  with  different  arrival  times  and  known,  fixed  precedence  constraints  to  be  scheduled  in  a 
hard  real-time  system.  This  algonthm  can  be  thought  of  as  a  deadline  inhentance  algonthm,  whereby  an 
activity  is  scheduled  as  if  it  had  a  deadline  "close"  to  that  possessed  by  another  activity  that  both  depends 
on  it  and  has  a  nearer  deadline.45  Unfortunately,  these  precedence  constraints  are  fixed,  making  a 
straightforward  extension  to  handle  resource  requirements  difficult.  Also,  no  effort  is  made  to  handle 
overload  cases,  since,  by  Blazcwicz's  definition,  a  missed  deadline  means  that  the  enure  system  has  failed. 

[Cheng  86]  looks  only  at  precedence  constraints,  while  [Zhao  87]  looks  at  both  precedence  constraints 
and  resource  requirements.  In  both  cases,  these  represent  extensions  of  [Ramamntham  84]  and  share  the 
same  shortcomings  —  they  attempt  to  make  guarantees  to  run  specific  activiues  at  the  possible  expense  of 
more  urgent  or  more  important  activities  that  may  amve  later,  and  the  guarantees  arc  not  truly  guarantees 
since  unanticipated  problems  can  prevent  their  fulfillment.  In  addition,  although  [Zhao  87]  presents  a  more 
dynamic,  less  restneuve  model  than  that  presented  in  most  of  the  work  in  this  area,  knowledge  of  the 
specific  resource  requirements  of  any  activity  to  be  run  is  still  assumed  to  be  known  in  advance 

[Lawler  73]  deals  with  precedence  constraints  when  scheduling  a  group  of  activities  on  a  single  machine 
and  presents  an  algonthm  that  uses  a  monotone  cost  function  to  dense  a  schedule  that  minimizes  the 
maximum  of  the  incurred  costs.  However,  the  activiues  to  be  scheduled  have  no  deadlines,  nor  do  they 
have  any  resource  requirements.  [ELsaycd  82]  presents  hcunstics  to  schedule  a  set  of  activities  that  share 
resources  to  complete  a  project.  Once  again,  there  are  no  deadlines  associated  w  ith  any  of  the  activiues. 

Some  of  the  previous  references  deal  with  uniprocessor  scheduling,  and  some  deal  w  ith  multiprocessor  or 
multiple  processor  scheduling.  This  distinction  was  not  made  previously  because  the  number  of 


*5ln  face  one  view  of  the  DASA  algorithm  to  he  examined  tn  the  thesis  work  is  exactly  this  It  incorporates  the  idea  that  the 
activities  on  which  some  activity  depends  must  be  dealt  with  betorr  the  activity  's  deadline,  as  must  the  activity  useli  However,  tn 
addition,  the  algonthm  assesses  the  situation  to  decide  if  there  is  currently  an  overload,  and  if  so,  selects  the  subset  ot  activities  to  be 
run  according  to  a  meaningful  metnc 
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processors,  although  certainly  an  important  consideration46,  is  of  secondary  concern  for  the  work  at  hand. 
The  pnmary  issues  being  addressed  when  comparing  and  contrasting  those  efforts  with  this  one  are: 
whether  or  not  time  constraints  are  dealt  with  explicitly,  the  amount  and  type  of  information  on  which 
scheduling  decisions  are  based,  and  the  fundamental  nature  of  applications  (whether  they  are  static  or 
dynamic,  periodic  or  aperiodic:  whether  overloads  can  occur  and  if  so  how  they  are  handled).  And, 
although  a  great  deal  of  work  has  touched  on  vanous  aspects  of  the  thesis  problem,  none  of  this  work  has 
addressed  all  of  the  key  issues  at  once. 

6J.  Other  Related  Work 

The  computational  model  presented  in  this  thesis  provides  for  the  abortion  of  an  activity.  This  is  done  for 
two  reasons.  First  of  all.  in  any  application,  if  an  activity  that  manipulates  shared  resources  is  to  be 
terminated,  unless  specific  steps  are  taken  there  is  a  danger  that  the  shared  resources  will  either  be 
unavailable  for  use  by  other  acnvities  or  left  in  an  inconsistent  state.  The  abort  mechanism  addresses  this 
problem  by  allowing  the  shared  resources  to  be  returned  to  an  acceptable  state  for  later  use.  Secondly,  an 
abort  mechanism  similar  to  that  just  mentioned  can  be  used  to  support  an  atomic  transaction 
facility  [Eswaran  76].  The  ability  to  include  such  a  powerful  facility  in  real-time  systems  is  inviting47,  and 
the  work  presented  here  can  assist  in  making  this  feasible  at  some  point.  Some  work  has  already  been  done 
along  those  lines.  Often,  this  has  involved  changing  the  concurrency  control  features  found  in  traditional 
database  transaction  managers  (  [Laskov  83.  McKendrv  85.  Sha  85]).  Other  work  has  examined  the 
problem  of  scheduling  transactions  using  the  standard  concurrency  control  rules.  However,  the  models 
chosen  for  work  in  this  area  (  [Liu  88],  for  example)  usually  require  detailed  prior  knowledge  of  the  precise 
resource  requirements  and  exact  access  and  release  timings  for  each  resource  in  each  transaction.  This 
thesis  addresses  a  more  dynamic  model  than  that. 

Finally,  a  few  other  research  directions  should  be  mentioned  to  put  this  work  in  ns  proper  context.  An 
underlying  assumption  of  this  work  is  that  dependencies  among  component  acnvities  arc  a  natural  product 
of  complex,  dynamic  real-time  systems.  There  is  some  work  that  attempts  to  approach  the  construction  of 
applications  from  other  points  of  view  [Herlihv  88]  explores  an  approach  that  would  eliminate  [he  need  for 
any  activity  to  wait  on  other  activities  when  accessing  resources.  However,  this  approach  does  not  allow 
the  maintenance  of  mutually  consistent  resources,  which  is  often  important  in  real-time  systems.  [Birman 
88,  Joseph  88]  outline  pornons  of  a  scheme  that  allows  application-specific  consistency  constraints  to  be 
satisfied  by  utilizing  a  set  of  communication  and  replication  mechanisms.  How  to  specify  the  behavior  of 
objects  that  have  been  composed  in  this  way  so  that  large  applications  can  be  constructed  using  a  modular 
design  methodology  is  an  important  open  question  with  respect  to  this  approach. 


**Notr.  for  instance,  that  a  scheduling  algorithm  dial  is  optima!  for  a  uniprocessor  may  not  be  optimal  for  a  multiprocessor.  A 
simple  deadline  scheduler  with  no  overloads  demonstrates  this  fact. 

47In  fact.  (Jensen  76)  suggests  using  transactions  not  only  for  real-time  applications,  but  aLso  within  a  decentralized  operating 
system  that  support*  these  applications. 
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Appendix  A 

The  General  Scheduling  Automaton  Framework 


In  order  to  provide  a  formal  framework  in  which  to  discuss  scheduling  policies  for  real-time  activities,  the 
following  model  has  been  adopted. 


Notation  The  following  conventions,  modeled  after  the  style  used  by  Maurice  Herlihy,  are  employed  in 
defining  the  computational  model  and  the  automa'on  that  will  examine  schedules: 

•  Identifiers  written  in  all  capital  letters  denote  domains  of  values  (e  g.,  TIMESTAMP) 

•  The  automaton  that  evaluates  schedules  lias  certain  state  components  associated  with  it;  these 
are  designated  by  identifiers  that  begin  with  a  single  capital  letter  followed  immediately  by  one 
or  more  lower-case  letters  (e  g..  Total,  AbortClock) 

•  Operations  are  accepted  by  the  automaton  if  they  meet  certain  preconditions 

•  Following  operation  execution,  certain  postconditions  hold;  when  these  result  in  modifying  the 
value  of  a  state  component,  the  new  value  is  followed  by  an  apostrophe  (e  g..  Clock'  =  Clock  + 

1) 


The  Model 

1.  An  application  is  composed  of  a  set  of  activities,  each  of  which  comprises  a  sequence  of 
computational  phases.  At  any  given  time,  these  activites  can  be  referred  to  by  means  of  the 
phase  that  they  are  currently  carrying  out.  Therefore  the  set  of  activities  can  be  represented 
by  the  set  of  phases  currently  defined:  j p0,  pr  p2.  ■  ■  ■  ) 

2.  While  executing  an  application,  an  observer  located  within  the  operating  system  could 
monitor  a  sequence  of  ome-stamped  events  passing  to  and  from  the  scheduler.  These  events 
are  of  the  form: 

'rvrn,  opiparms)  0 

where, 

t  is  a  timestamp, 

op  is  the  operation  associated  with  the  event  (as  defined  below). 
parms  are  the  arguments  for  the  operation. 

0  is  the  originator  of  the  event  (either  p,  for  a  phase,  or  S, 
for  the  scheduler) 

A  sequence  of  these  events  is  called  a  history.  Notice  that  some  of  these  events  are  generated 
by  individual  phases  and  some  are  generated  by  the  scheduler. 
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?.  make  a  real  table]  The  operations  that  may  occur  in  events,  and  the  potential  originators  of 
each,  include: 


Event 

Potenual  Onginatorts) 

•  request  -phase!  v,  itxpecled) 

Phase 

•  abort-phasetp) 

Scheduler  or  Phase 

•  preempt-phasetpt 

Scheduler 

•  resume-phasetp ) 

Scheduler 

•  request!  r) 

Phase 

*  g'-onttp,  r.  tundo) 

Scheduler 

4.  The  individual  computational  phases  that  comprise  an  activity  are  delimited  by 
request-phase'  events.  A  request-phase'  event  ends  one  computational  pha-;e  of  an  activity 
and  begins  the  next  atomically. 


5.  Phases  may  access  shared  resources.  A  request  for  such  access  is  s.cnalled  by  a  phase  by 
means  of  a  'request'  evert  for  the  specific  resource  desired.  Permission  to  access  a  shared 
resource  is  signalled  to  the  phase  by  means  of  a  ‘grant’  event. 

6.  .Ail  shared  resources  that  are  held  by  an  activity  must  be  released  at  the  compleuon  or 
abortion  of  each  computational  phase. 

7.  At  any  given  time  there  is  one  phase  that  is  acDve.  It  may  be  preempted  by  the  scheduler 
This  is  signalled  by  a  '  preempt-phase'  event.  The  scheduler  may  subsequently  determine  that 
the  phase  should  be  resumed;  this  is  signalled  by  a  resume-phase'  event. 

8.  A  history'  is  defined  as  a  sequence  of  events.  Not  all  histones  are  meaningful  or  well-formed. 
Let  e0,  ej.  e,  ...  denote  events.  Then,  formally,  a  history.  //.  can  be  denoted  as: 

H  =  eo  e\  e2  ■■  en 
where  the  operator  denotes  concatenation. 

Informally,  a  projection  of  a  history  selects  certain  events  from  a  history,  preserving  their 
relative  postions  in  the  projection.  Therefore,  a  projection  of  a  history  could  include  all  of  the 
request-phase's  from  the  history  or  all  of  the  events  that  dealt  with  a  specfic  phase.  The 
symbol  denotes  a  projection.  So  for  example,  H  |  p  represents  the  projection  of  history  H 
onto  phase  p.  This  projection  would  include  all  of  the  events  that  were  originated  by  phase  p 
or  that  were  originated  by  the  scheduler  and  included  p  as  an  operational  parameter 

9.  Some  additional  terminology  and  notation  will  be  useful  for  discussing  events.  Let  an  event, 
e  represent  the  following  event: 

«  =  'exem  op(parms)  O 

Then  define  the  following  simple  functions: 

timestampie)  =  t 

event!} pel  e)  =  op 


sourceie)  =  0 
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10.  The  conditions  that  define  a  well-formed  history  include 44 : 

•  event  timestamps  must  increase  monotomcally  and  must  be  unique  —  test:  examine  the 
timestamps  on  events;  for  example,  apply  the  function  nmestampsOKf)  to  a  history  H  to 
verify  that  it  meets  this  requirement,  where  time  stamp  sOK{)  is  defined  as: 

timestampsOK(6)  =  timestampsOK(e)  =  true 
timestampsOKie^  e^-hf)  = 

false.  if  timestampie  {) 

>  timestampie-.) 

r  i  me  stamp  sOKtH),  otherwise 

•  request  for  a  resource  must  appear  in  the  schedule  before  the  corresponding  grant  — 
test  for  each  'grant'  event,  search  the  history  of  the  phase  in  which  the  'gran:' 
occurred  for  a  preceding  '  request'  for  the  same  resource 

•  a  phase  cannot  be  preempted  if  it  is  not  active;  it  cannot  be  resumed  if  it  is  active;  and 
so  on  —  simple  tests  check  all  of  these  conditions 

•  a  given  phase  either  commits  or  aborts;  the  events  assure  that  a  singel  phase  cannot  do 
both;  however,  a  well-formed  history  must  have  at  most  one  'abort-phase'  event  for 
any  given  phase  —  test  examine  the  history  for  the  occurance  of  two  or  more  'abort- 
phase'  events  for  a  single  activity  that  are  not  separated  by  a  'request-phase'  event. 

•  expected  compute  rime  is  accurate  —  test:  check  that  the  estimated  computation  time 
equals  the  actual  computational  time  used,  for  example,  the  following  test  could  be 
applied: 

cttestlhf)  = 

(V p)(comptimeOK(H  |  p)  v phaseabortedlH  \  p)v phaseunfinishedtH  |  p)) 

where. 


**Il  is  not  always  clear  that  a  specific  lest  be  a  requirement  of  a  well-formed  history  or  whether  it  is  a  requirement  thal  determines 
which  histones  will  be  accepted  by  a  given  automaton-  There  is  no  question  that  the  proper  temporal  ordering  of  events  is  a 
requirement  for  a  well-formed  history;  however,  tests  that  constrain  the  relative  ordering  of  specific  events  —  for  instance,  request' 
and  'grant  events  —  in  a  history  are  not  so  obvious!)  requirements  for  a  well-formed  history.  As  a  result,  this  list  is  merely  an 
attempt  to  lay  down  an  initial  set  of  tests.  Some  of  these  tests  need  not  be  done  prior  to  submitting  the  history  to  an  automaton  —  in 
those  cases,  the  automaton  will  enforce  the  requirements  verified  by  the  tests  in  question. 
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comptimeOK(p.O)  =  compcimeOK(p.e)  =  0 

comptimeOKlp.e  ^e+H)  = 

t^-t\+comptimeOK(H),  if(«’l=/1  resume-phase{p)  S 

ve,=f,  grantlp)  S) 

Me^ =fi  preempt-phase(p)  S 

ve2=t2  reQuestir )  P) 
if j=f  j  resume-phaseip)  S 

v*j=r,  grantip)  S) 

/ \(e^=t-2request-phase(v.t )  p 
ve,=f;  abon-phaseip )  O) 

phaseaborted(p.O)  =  false 
phaseabortedtp.e-H)  = 

if  e=t  abort-phase(p)  O 

false ,  i(e=tx  request-phaselv.tf)  P 

phaseabortedipdf).  otherwise 

phaseunftnishedip.O)  -  true 

phaseunfinishedip.e  hf)  = 

/a/se.  if  e=t  abort-phase(p)  0 

vf=/j  request-phase(v Jf)p 
phaseunfimshed(pJi).  otherwise 

•  expected  abort  time  is  accurate  —  test:  similar  to  the  presious  test 

•  estimated  computation  time  required  for  a  phase  must  always  be  greater  than  or  equal 
to  zero49  —  test:  straightforward  inspection  of  each  'request-phase'  event  in  the 
history 

•  no  request'  event  should  request  shared  access  to  the  nullresource  —  test: 
straightforward  inspection  of  each  request’  event  in  the  history 

11.  The  state  components  associated  with  the  scheduling  automaton  framework  are: 

•  ExecMode:  PHASE  — >  MODE  (MODE  is  either  'normal'  or  abort’) 

•  ExecClock:  PHASE  -» VIRTUAL-TIME 

•  AbortClock:  PHASE  — *  VIRTUAL-TIME 

•  ResumeTirne:  PHASE —» TIMESTAMP 

•  Value:  PHASE-* (TIMESTAMP -» VALUE) 

•  Total:  VALUE  (initially  ’O') 

•  RunningPhase:  PHASE  (initially  'nullphase') 

•  PhaseElect:  PHASE  (initially  'cnormal,  nullphaso’l 

•  PhaseList:  list  of  PHASE  (initially  'O’) 

•  Other  state  components  are  also  associated  with  the  automaton.  These  are  used  to 


49 An  additional  requirement  may  also  be  placed  on  the  parameters  of  a  'request-phase'  event:  the  value  function  must  be  of  the 
appropriate  form,  as  outlined  below.  This  requirement  his  not  been  included  in  this  list  because  the  tests  that  are  present  all  apply  to 
the  general  case  of  scheduling  with  dependency  considerations  in  a  real-tinv*  environment  using  information  available  from  arbitrary 
time-value  functions.  This  requirement  is  related  to  a  simplification  made  to  make  the  work  more  clear  and  more  manageable,  and  so 
does  not  seem  to  cany  the  same  weight  as  the  others  listed  above. 
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handle  some  of  the  bookkeeping  details  for  the  specific  scheduler  being  used.  The 
components  that  appear  above  are  intended  to  reflect  the  state  that  any  specific 
scheduler  would  need  and  maintain  under  this  general  model. 

Specific  initial  values  may  be  given  to  many  of  these  state  components  in  order  to  satisfy  the 
requirements  of  a  given  automaton. 

12.  Operations  recognized  by  the  automaton  and  their  general  minimal/skeletal  preconditions  and 
postconditions: 

*  ‘event  request-phaselv.  ttxpecled)p: 

preconditions: 

true  <No  preconditions  here  so  that  interrupts  and  other  new  phases 
can  occur  at  any  time> 

postcondinons: 

if  (RunmngPhase  =  p)  then 

if  (ExecMode(p)  =  normal)  then 

Total’  =  Total  +  Value(p)(tevcnt) 
else 

;no  value  for  aborted  phase 
;release  the  resources  acquired  during  the  phase 

;accept  values  for  scheduling  parameters 

Value’fp)  =  v 

ExecClock’Cp)  =  texpected 

AbortClock’(p)  =  0 

ExecMode'fp)  =  normal 

mote  that  p  is  not  resource-waiting 

;make  sure  p  is  pan  of  the  list  of  phases,  if  necessary 
,f  (‘expected  >  °)  ^0 

PhaseList’  =  PhaseList  u  (p  1 

else 

PhaseList’  =  PhaseList  -  (p) 

*  'event  abort -phase(p)  O 

preconditions: 

<Specific  to  the  scheduler  under  consideration> 
postconditions: 

ExecMode’fp)  =  abon 
ResumeTime’(p)  =  tevenf 

*  t even, PreemP‘ -phase(p)  S: 

preconditions: 

<Specific  to  the  scheduler  under  consideration> 
postconditions: 

if  (ExecMode(p)  =  normal)  then 

ExecClock’fp)  =  ExecClockfp)  -  (tevem  -  ResumeTime(p)) 
else 

AbonGock’(p)  =  AbonOock(p)  -  (tevem  -  ResumeTime(p)) 

*  ‘event  resume-phase(p)  S: 

preconditions: 

<Specific  to  the  scheduler  under  considerarion> 
postconditions: 

ResumeTime’(p)  =  tevem 

*  'event  request!  r)  p: 

preconditions: 
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<Specific  to  the  scheduler  under  constderatton> 
postcondiaons: 

ExecClock’(p)  =  ExecClock(p)  -  (tevem  -  RcsumeTime(p)) 
'  ’event  gran‘(p.  r.  undotime(r))  S: 
preconditions: 

<Spectfic  to  the  scheduler  under  consideration> 
postcondiaons: 

ResumeTime’(p)  =  teven( 

AbortClock’(p)  =  AbortClock(p)  +  undotime(r)50 


Specific/Simplifying  Assumptions/Restrictions  Time-value  functions  are  all  of  the  form: 
v(t)  =  (step(val.  tc))(t), 

where, 

tc  is  the  critical  time,  or  deadline,  for  this  phase  of  an  activity, 

val  is  the  value  associated  with  completing  a  phase  at  any  time  before  its  deadline, 

stepfval,  tc)(t)  =  val,  t  <  tc 

0.  t  >  tc 


,0The  function  'undotime()'  indicates  the  amount  of  time  that  will  he  required  to  restore  the  resource  just  acquired  to  its  current 
slate.  This  function  may  vary  from  system  to  system  and  from  application  to  application.  Consequently,  tor  the  purposes  of  this 
work,  it's  place  and  role  have  been  indicated  without  applying  a  single  definition  for  this  function. 
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Appendix  B 

Derivation  of  DASA/ND  Scheduling  Automaton 


General  /Introduction.  When  there  are  no  dependency  considerations  —  as  when  comparing  the  Dasa 
algorithm  to  LBEa  —  some  simplifications  can  be  made  to  the  formulae  that  define  dasa.  These 
simplifications  aid  in  allowing  direct  comparisons  to  be  made  between  algorithms.  The  following 
derivation  points  out  and  justifies  these  simplifications. 

In  each  simplification  that  follows,  the  original  formula  to  be  simplified  is  taken  directly  from  the 
descnpuon  of  the  Dasa  Algonthm.  The  derivation  of  the  simplification  is  then  offered 


The  Functional  Definition  of  SelectPhaseO. 

1.  By  definition,  the  fact  that  there  are  no  dependencies  means  that  there  is  no  interaction  or 
cooperanon  among  phases  through  shared  resources.  (Otherwise,  there  would  be  a  risk  of  a 
dependency  arising .)  In  the  model  presented  here,  this  situation  is  represented  by: 

( Vp  )ResourceRequ  ested(p  )=nu  ll  resource 

2.  Simplification  (1)  allows  the  definition  of  Dept)  to  be  transformed  from 

Depip 1  =  nullphase,  i IResourceRequestedip) 

=nullresource, 

Owner(ResourceRequested{p)),  otherwise 


to 

Depip)  ~  nullphase 

3.  Simplification  (2)  leads  directly  to  the  transformation  of  the  definition  of  the  function 
dependency  list( )  from 

dependencylist(p)  = 

6,  if  Dep(p)=nullphase 

dependency  hst{Dep(p))'-j\<J\o  rma  l  D  epip )  > ) , 

if  AbortC  lock!  Depip)) 

>  ExecClockiDepip)) 

\<abortDep(p)>),  otherwise 


to 


dependencylistip)  =  0 

4.  Simplification  (2)  also  leads  to  the  transformation  of  the  function  PVD()  from 

PVD(p)  =  0,  if  ExecModeip)=abort, 

otherwise 


Val(p)+PV(Dep<p)) 


ExecClockfp)+PT(Dep{p))' 


to 
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PVD(p)  =  0, 

Val{p ) 

ExecC  lockxp)' 


if  Exec\fode(p)=abort, 
otherwise 


PUp)  =  0. 

0. 

Val(p)+PV(Dep{p))x 

PT(p)  =  0, 

AbortClockip), 

ExecC  lock{p)+PT(Dep(p)), 
5.  Applying  Simplification  (3)  transforms 
tobescheduled(P)  = 


i  lp=nuUphase, 
if  AbortClockip) 

<  ExecC  lock{p), 
otherwise 

if  p=nullphase, 
if  AbortClockip) 

<  ExecC  lockfp), 
otherwise 


( <normal,p>  }^idependencylist(p)^JtobescheduIed(P-\p ) ), 

if pe  P 


tobescheduled(P)  = 

0.  if  ,P=4> 

{<normal,p>)\jtobescheduled(P-{p}),  if pe  P 

which  is  further  simplified  (by  means  of  an  inductive  proof  on  the  number  of  elements  in  P) 


tobescheduled(P)  = 

0. 

( <normaip>  \  p€  P}. 

and  finally  to 

tobescheduled(P)  =  { <normal.p>  \  p  €  P ) 
6.  Consider  the  definition  of  mustcompletebyl ): 
mustcompleteby(t.P)  = 


ifP=6 

otherwise 


\p  |  [<normal.p>  €  tobescheduled{P)rJDeadlineip)<t]), 

otherwise 

Substituting  the  definition  of  tobescheduledl >  that  was  derived  in  Simplification  (5)  yields 
mustcomp!eteby(t,P)  = 

\p  )  [<normal,p>  e  \<normal.q>  |  q  6  P)ADeadhne(p)<t]), 

otherwise 

w  hich  is  equivalent  to  .  .  . 
mustcompletebyit.P )  = 


(pipe  P*Deadline{p )  <  1 1 
7.  Again,  applying  Simplification  (3)  allows 


otherwise 
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mustfinishbylt-P)  = 

0.  ifP=0w<^„( 

v  mustcompletebyUJ3)-o 

reduces  tj \ |  <normal.p> ) ^dependency  hst(p)-umusifinishbyU.P-{p ) )). 

if pe  mustcompletebyU.P ) 

to  become 

mustfinishby(t.P)  = 

6.  if  f=0vr<U 

v  mustcompletebyUJ’)=- 0 

reduced  J3.{<normal,p>}umustfinishbyU  J3-[p))), 

ifpe  mustcompletebyU.P) 

Consider  mustfinishbyi ;  for  r  >  t^,enI. 

Prove:  In  cases  in  which  there  are  no  dependency  considerations  and  for  which  t>tntn!. 
mustfinishbyi )  never  returns  a  set  that  includes  a  phase/mode  pair  for  which  the  mode  is 
abort.  That  is,  prove  that 

iyP){pmp  G  mustfinishbyi!  J3 )  Modeipmp )  *■  abort) 

Proof.  This  is  proven  by  induction  on  i.  the  number  of  elements  in  P.  the  set  of  phases  for 
which  mustfinishbyi )  is  being  evaluated. 

Basis,  i  =  0.  In  this  case.  P  =  0.  Therefore,  mustfinishbyi!  J3)  =  d,  and  the  claim  is  trivially 
true. 


Inductive  Step.  Assume  that  the  inductive  hypothesis  holds  for  all  sets  of  phases  with  i  or 
fewer  elements.  Show  that  it  also  holds  for  all  sets  of  phases  with  i+1  elements. 

Let  P  denote  a  set  of  phases  with  i+7  elements.  According  to  the  definition  of  mustfinishbyi ) 
given  above: 


mustfinishbyUJ ’)  = 

0. 


if  ,P=dvr<r 


v  musicompletebyUJ’)=t> 

reduced  J3^  <normal.p>)^imustfinishbyitJ3-[p))), 

i(pe  mustcompleiebyUd *) 

It  is  given  that  t>tfvtnr  and  since  t+7  >  0,  P* 0.  Consequently,  which  of  the  two  cases  in  the 
above  definition  applies  is  determined  solely  by  the  value  of  mustcompletebydJ3). 

If  mustcompletebytt.  P)  =  d.  then  mustfinishbyd,  P)  =  d.  too,  and  once  again  the  inductive 
hypothesis  is  trivially  true. 

Otherwise.  mustcompletebydJ3)  *0 In  that  case,  let  /?mf  e  mustcompletebyd  J3)- 
As  shown  in  Simplification  (6),  mustcompletebyl )  is  defined  as: 
mustcompletebydJ’)  = 

[p \pe  P rDeadline{p)<t\.  otherwise 

Since  mustcompletebyltj 3)  and  pmc  e  d,  then 

Pmc  6  (P  I P  e  PcJJeadlinelp )  <  t ) 

Therefore,  since  all  of  the  elements  in  this  set  are  members  of  P  ... 

Pme*F 

This  allows  the  value  of  mustfinishbyUJ3)  to  be  written  as  .  .  . 

mustfinishbyU.P)  =  reduced  J3.{<normal^mc>)urnustfintshbyd.P-\pmc})) 

Reduced  is  defined  as: 
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reduced  JJMP)  = 

reduced  JJMP-{<abortp>}),  if  <abort.p>.<normal.p>  e  PMP 

A<abort.p>  e  mustfimshbyiC .P) 
PMP,  otherwise 

It  is  given  that  P  has  i+J  elements,  and  it  has  been  proven  that  p  is  one  of  them. 
Consequently,  P-[pmc )  has  i  elements  and  the  inductive  hypothesis  asserts  that  .  . 

pmp  £  mustfimshby(i ,P -{p nc ) )  — > Modeipmp )* abort 

Also,  since  Modei<normalp  „".>)* abort,  the  enure  argument  passed  to  the  funcuon  reduced 
contains  no  phase/mode  pairs  for  which  the  mode  is  abort.  Therefore,  the  second  ca.se  in  the 
definition  of  reduced  applies,  and  reduced  acts  as  an  identity  function  for  this  particular  set 
of  arguments  . .  . 

reduceitJ,{<normal.pfnc>}^mustfinishbyi!j~{pmc\))  = 

{ <normal,pmc>\KjmustfinishbydJ-{pmc ) ) 

Inserting  this  fact  into  the  earlier  expression  for  mustfinishbyitj)  yields  .  . 

mustftnishby(t.P)  =  {<normal.pmc>)^imustfinishbydJ’-\pmc\) 

.Assume  pmp  &  mustfinishbyitj’).  Using  the  definition  for  mustfinishbyitj )  that  was  just 
presented  . .  . 

pmp  6  { <normal,pmc>  )\jmustfmishby(tJ-\pmc)) 
or  equivalently  .  .  . 

pmpe  { <normal.p ^>1  vpmpe.  mustfinishbyd.P-[pmc\) 

As  was  noted  earlier,  the  set  of  phases  P-\pmc\  has  i  elements,  so  the  inductive  hypothesis 
holds  and  asserts  .  . . 

pmp  e  mustfinishbyitj ~{pmc } )  — » Modeipmp)*  abort 
Yet  ... 

pmpi  mustfinishbyU.P-[pmc)) 

— » pmp  £  \<normalpmc>} 

— >  pmp=<normalp>mc> 

— »  Modeipmp)*  abort 

Applying  the  following  identity  from  formal  logic 
( A  — >  B)a(  — '  A  — >  B )  =  B 

to  the  last  two  implications  leads  to  the  conclusion  .  . 

Modeipmp )*  abort 

The  above  result  was  derived  by  assuming  pmps  mustfinishbv(tj).  Applying  another  formal 
logic  identity: 

AturnstileB  =  A  — »  B 

proves  .  .  . 

pmp  €  mustfinishbyitj)  — >  Modeipmp)  *  abort 

Therefore,  the  inductive  hypothesis  holds  for  all  sets  of  phases  P  with  /+/  members,  whether 
or  not  mustcompletebv(tj)  is  empty.  Q  E  D. 

Applying  this  result  to  the  definition  of  mustfimshbyd,  once  again  noting  that  reduced  will 
always  act  as  an  identity  function  since 

(VP)(pmp  €  mustfinishbyi  t.P)  — >  Modeipmp)  *  abort) 

yields  .  .  . 
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mustfinishby(t.P)  = 

6,  if /*=0  v  Kteven; 

v  mustcompletebyUT  >=0 

[<normalp>\^jmustfinishby(tJ>-{p)),  \{pe  mustcompleteby(t.P) 

Finally,  a  simple  induction  on  the  size  of  the  set  P  will  yield  .  .  . 
mustfinishbyitj1)  = 

0.  if  Psd  v  t<ieveru 

v  mustcompleteby(tj>)=-0 

{ <normal,p>  |  p  £  mustcompleteby{tJ>) } . 

otherwise 

8.  In  the  formulation  of  the  dasa  scheduling  algorithm,  the  function  timerequiredbyO  is  only 
evaluated  with  a  result  from  mustfinishbyO  (ignoring  the  recursive  evaluations  that  are  part  of 
the  definition  of  timerequiredbyO).  As  a  short  inductive  proof  would  indicate,  in  that  case 
timerequtredbyO  can  be  simplified  since  (as  shown  in  Simplification  (7))  mustfinishbyO 
returns  no  phase/mode  pairs  that  have  an  abort  mode.  Therefore,  timerequiredbyO  never 
receives  an  argument  containing  a  phase/mode  pair  of  the  form  <abort.  p>,  and  it  can  be 
simplified  from  .  .  . 

timerequiredby(PMP)  = 

6,  if  PMP=t> 

ExecCloclc{p)+timerequiredby(PMP-{  <normal.p> ) ), 

if  <normal,p>  E  PMP 

AbortClock(p)+timerequiredby(PMP-{<abort,p>)), 

if  <abortp>  £  PMP 


to  .  .  . 

ttmerequiredby(PMP)  = 

0,  if  PMP=t 

ExecClocic(Yp)+ttmerequiredby(PMP-{<normal,p>}), 

if  <normal.p>  6  PMP 

9.  PickoneO  is  also  only  evaluated  for  an  argument  that  is  a  result  returned  by  evaluating 
mustfinishbyO.  Once  again,  since  mustfinishbyO  never  returns  a  set  containing  an  element 
that  is  a  phase/mode  pair  with  an  abort  mode.  pickoneO  can  be  simplified  from  .  .  . 


pickone(PMP)  = 

<normal.p>. 

<abon,p>. 


<normal,nullphase>. 


to  .  .  . 


if  <normal.p>€  PMP 
o£>ep(p)=nu!lphase 
if  <abortp>  £  PMP 
r,--(3q)(<Jtormal.q>€  PMP 
rDep(q)=nullphase) 
otherwise 


ptckone(PMP)  = 

<normal,p>,  if  <norma!.p>  €  PMP 

rX>ep(p)=nullphase 

<norma!.nullphase>.  otherwise 

Since,  according  to  Simplification  (2),  (V p)Dep(p)=nullphase  .  . 
pickone(PMP)  = 

<normal,p>,  if  <normal,p>  e  PMP 

<normal,nullphase>,  otherwise 


Finally,  this  function  can  be  rewritten  as 
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pickone(PMP)  = 

<normal.nullphase>,  \{PMP-=C> 

<normal,p>  |  <normalp>  €  PMP,  otherwise 


10.  As  shown  in  Simplification  (4)  above  .  .  . 
PVD(p)  =  0. 

Val{p) 

ExecClochp)' 


if  ExecMode{p)=abort, 
otherwise 


.As  shown  in  Simplification  (9),  pickone()  will  never  return  a  phase/mode  pair  as  a  result 
whose  mode  is  abort.  As  a  result,  the  precondition  for  accepting  an  ’abort-phase’  event  for 
the  dasa  automaton  will  never  be  satisfied.  Since  the  postconditions  of  'abort-phase'  are  the 
only  way  that  ’ExecMode’  can  be  changed  to  ’abort’  for  any  phase,  then  . .  . 

(V  p)ExecMode(p)=normal 


This  allows  the  first  case  in  the  definition  of  PVDt /  to  be  dropped,  yielding 


PVD(p)  = 


Val(p) 

ExecCloddp) 


The  Simplified  Definition  of  the  Automaton.  There  are  also  a  set  of  simplifications  that  can  be  made  to 
the  automaton  itself  when  there  are  no  dependencies  to  consider.  Each  of  these  simplifications  are 
discussed  in  turn. 

1.  As  pointed  out  before,  all  of  the  simplifications  stem  from  the  fact  that  .  . . 

( V  p)ResourceRequested( p  )=nullresource 
Consider  the  postconditions  defined  for  a  ’request'  event: 

ExecC  lock' (A  )=ExecC  lock(A)-(ta-ResumeTime(A)) 

ResourceRequestecf(A)=r  ;  indicate  A  is  resource-waiting 

PhaseElect’-SelectPhase{PhaseList) 

RunnmgPhase=nullphase  ;  give  up  processor  until  ’grant’ ed  resource 

They  necessarily  include  an  assignment  to  ResourceRequested  for  some  phase,  it  must  be  the 
case  that  no  ’request’  event  can  be  accepted  by  the  simplified  dasa  automaton.  Therefore, 
the  precondition  for  the  acceptance  of  a  ’request’  event  is  false ,  and  the  event  can  be 
eliminated  from  the  automaton. 

2.  Similarly,  consider  the  precondition  for  the  acceptance  of  a  grant’  event: 

( RunningPhase=nullphase)MPhase{PhaseElect)=A)/\(r *  nullresource) 

/\(ResourceRequested(Phase{PhaseElect))=r)/\(Mode(PhaseElect)=normal) 

Since  it  includes  as  conjuncts  (ResourceRequested{Phase{PhaseElect))=r)  and 
(r*  nullresource),  this  precondition  can  never  be  sausfied  because 
( Vp)ResourceRequested(p)=nullresource .  Therefore,  this  precondition  will  always  be  false,  a 
’grant’  event  can  never  be  accepted,  and  the  event  can  be  eliminated  from  the  simplified 
Dasa  automaton. 

3.  Consider  the  precondition  for  the  acceptance  of  a  'resume-phase'  event: 

( RunningPhasr=nullphase)A(Phase(PhaseE!ect)=A)/\(Phase(PhaseElect)*.  nullphase ) 

/ \-^ResourceWainng(Phase{PhaseElect))MMode(PhaseE!ec[)=normar) 

In  particular,  consider  the  conjunct  —  ResourceWaiting(Phase(PhaseElect)),  remembering 
that,  by  definition  .  .  . 

ResourceWauing(p)  =  {3r)(ResourceRequesied(p)=rra-*  nullresource /\Ov.nerir)*p) 

ResourceWaitmgQ  must  be  false  for  all  phases,  implying  that  —  ResourceWaiting(p)  must  be 
true  for  all  phases  p.  Therefore,  the  prccondiuon  for  the  acceptance  of  a  'resume-phase' 
event  may  be  simplified  to: 
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(RunmngPhase=nullphase)MPhase{PhaseElect)=A  )/\(Phase(PhascElect  \  *  nullphase) 

/ \(Mode(PhaseElect)=normal) 

4,  The  postconditions  associated  with  a  'request-phase'  event  include: 

;release  the  resources  acquired  during  the  phase 
for  r  in  ResourcesHeld(A) 

Owner'(r)=6 
ResourcesHeld  (A  )=6 

ResourcesHeld  is  initially  set  to  6  and  is  only  altered  by  the  postconditions  accompanying  the 
acceptance  of  a  ’grant'  event.  Since  it  was  shown  in  simplification  2,  that  there  can  be  no 
grant’  events,  then  these  actions  concerning  ResourcesHeld  in  the  postconditions  for  a 
’request-phase’  have  no  effect.  Furthermore,  Owner  is  initially  set  to  nullphase  and  is  only 
changed  as  a  result  of  the  postconditions  that  accompany  the  acceptance  of  a  ’grant’  event. 
Consequently,  all  of  the  postconditions  listed  immediately  above  can  be  eliminated  from  the 
simplified  dasa  automaton  without  ill-effect.  In  fact,  the  state  components  Owner, 
ResourcesHeld,  and  ResourceRequested  can  all  be  eliminated  from  the  automaton  as  well. 

5.  Consider  the  precondition  for  the  acceptance  of  an  ’abort-phase’  event: 

(RunningPhase=nullphase)r\(Phase(PhaseElect)=A)f\(Mode(PhaseElect)=abort) 

In  particular,  consider  the  conjunct  ( Mode(PhaseElect)=abort ).  PhaseElect  always  receives 
its  value  as  a  result  of  the  following  evaluation: 

PhaseElect' =SelectPhase(PhaseListr) 

and  .  .  . 

SelectPhase(P)  = 

pickone(,mustfirushby(DLrirsl(pmplist)J>schtdul'/[p\ ,p2,p3 ) ))), 

where 

pmphst  =tobescheduled(Psch'dulf/ {p  l  ,p2p3  ] )) 
pickone(PMP)  = 

<normal.nullphase>,  \{PMP=6 

<normal,p>  \  <normalp»  6  PMP,  otherwise 

Under  no  circumstances  will  this  return  a  phase/mode  pair  with  a  mode  indicating  abort 
Therefore,  the  conjunct  ( Mode{PhaseElea)=abort )  will  always  be  false  and  the  entire 
precondition  is  always  false.  Consequently,  the  enure  'abort-phase'  portion  of  the  Dasa 
automaton  may  be  omitted  in  the  simplified  version. 


0Mr'0M^0^0^0^0^0Ji0^0^0^0^a0^0 


RADC  plans  and  executes  research ,  development,  test  and 
selected  acquisition  programs  in  support  of  Command,  Control, 
Communications  and  Intelligence  (C3I)  activities.  Technical  and 
engineering  support  within  areas  of  competence  is  provided  to 
ESD  Program  Offices  (POs)  and  other  ESD  elements  to 
perform  effective  acquisition  of  C3I  systems.  The  areas  of 
technical  competence  include  communications,  command  and 
control,  battle  management  information  processing,  surveillance 
sensors,  intelligence  data  collection  and  handling,  solid  state 
sciences,  electromagnetics,  and  propagation .  and  electronic 
reliability  maintainability  and  compatibility 
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